Client work

Staying accountable for operational software as the product changes.

An outside Canadian software-product client engaged Amidship on a mobile fundraising and auction platform for charities and event teams. The relationship began in 2016; paid software-development work is documented in 2026.

Relationship began 2016 · paid development documented 2026

  • Client work
  • Relationship began 2016
  • Paid development documented 2026
  1. Workflow
  2. Application
  3. Integrations
  4. Operations
  1. 2016 agreement
  2. 2019 development
  3. 2024 product changes
  4. 2025 support
  5. 2026 development
The evidence spans product, application, integration, and operational work across multiple dated checkpoints.

The problem

Operational software keeps changing after launch.

A fundraising event platform brings together workflows that become consequential at exactly the moments they cannot be casually changed: registration, bidding and donations, auction close, payments, invoices and receipts, messaging, reporting, and operator administration.

Behind those workflows sit time zones, currencies, integrations, infrastructure, and established product behaviour. Over time, providers, compliance requirements, dependencies, and operating needs change. The job is not simply to add the next feature. It is to make responsible changes without breaking the system around them.

Key decision

Treat maintenance and evolution as product work: understand the workflow, change the smallest responsible layer, and keep production behaviour explicit.

Working across the product, not around it.

Amidship's engagement has included Rails architecture and code review, custom software development, maintenance, bug fixes, enhancements, staged releases, and technical consulting.

Within the product, verified work spans auction and event lifecycle, bidding and donations, payments and invoicing, messaging and notifications, reporting, time-zone and currency handling, sponsor and administration workflows, and production infrastructure and support. Repository history documents product and infrastructure changes through 2024; technical support is documented in 2025; paid software-development work is documented in 2026.

  • Auction + event lifecycle
  • Patrons, bidding + donations
  • Payments, invoices + receipts
  • Messaging + notifications
  • Reporting + administration
  • Infrastructure + production support
  1. Event setup
  2. Registration
  3. Bidding + donations
  4. Auction close
  5. Payments + invoices
  6. Reporting + follow-up
  • Messaging + notifications
  • Administration + sponsors
  • Time zones + currencies
  • Production infrastructure + support
  • Architecture
  • Development
  • Maintenance
  • Enhancement
  • Production support
Mature operational software changes across the workflow and the layers underneath it.

Documented checkpoints

A relationship evidenced across years.

The public case study does not reproduce private client material. Internally, the engagement is substantiated by dated corporate, repository, billing, and support records.

  1. 2016 services agreement relationship + engineering scope

    2016 — engagement begins. A services agreement establishes the Amidship–client relationship and covers custom software development, Rails architecture and code review, maintenance, bug fixes, enhancements, staged approval, delivery reporting, and technical consulting.

  2. 2019 corporate invoices paid software development

    2019 — paid development documented. Corporate software-development invoices provide an additional dated checkpoint for Amidship's work on the platform.

  3. 2024 private repository active product changes

    2024 — product work remains active. The private production repository records product changes through July 2024, including patron-facing and operational application work.

  4. 2025 support correspondence operational support

    2025 — operational support documented. Technical-support correspondence records Amidship helping with production email-domain / DMARC behaviour around the platform.

  5. 2026 corporate invoice paid software development

    2026 — paid development documented again. A May 2026 invoice records current software-development work for the client.

Private source material reviewed by Amidship; confidential documents are not reproduced.

Why this matters

Most important software accumulates history.

A mature product rarely presents a clean greenfield problem. Existing workflows, data, integrations, infrastructure, edge cases, and user expectations all constrain what a responsible change looks like.

This engagement shows Amidship working through that history rather than treating every request as a rewrite: understand current behaviour, preserve what matters, change what needs to change, and keep the product operable.

  • Stay accountable beyond an initial launch or build phase.
  • Work safely inside an established software product rather than defaulting to a rewrite.
  • Connect operating rules to product behaviour, architecture, and implementation.
  • Evolve payments, messaging, reporting, compliance-sensitive integrations, and infrastructure as requirements change.
  • Treat production support and maintenance as engineering work, not an afterthought.

Evidence boundary

This is an anonymized client engagement. Public copy is limited to facts substantiated by Amidship's private contract, repository, invoices, and correspondence. It does not disclose client identity or reproduce private/client-owned materials, and it makes no claims about customer counts, fundraising volume, transaction volume, adoption, uptime, revenue, ROI, conversion, or business outcomes. The dated evidence establishes a relationship that began in 2016 and paid software-development work documented in 2026; it does not claim uninterrupted full-time delivery across every intervening period.