Client work
Staying accountable for operational software as the product changes.
Over a long-running relationship, Amidship has helped a Canadian software-product company evolve a mobile fundraising and auction platform for charities and event teams — across product behaviour, integrations, infrastructure, and production support.
Operational software · Long-running client relationship
- Workflow
- Application
- Integrations
- Operations
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.
Over the life of the engagement, Amidship has worked across auction and event workflows, bidding and donations, payments and invoicing, messaging and notifications, reporting, time-zone and currency handling, sponsor and administration workflows, and the infrastructure and production support around the product.
- Auction + event lifecycle
- Patrons, bidding + donations
- Payments, invoices + receipts
- Messaging + notifications
- Reporting + administration
- Infrastructure + production support
- Event setup
- Registration
- Bidding + donations
- Auction close
- Payments + invoices
- Reporting + follow-up
- Messaging + notifications
- Administration + sponsors
- Time zones + currencies
- Production infrastructure + support
- Architecture
- Development
- Maintenance
- Enhancement
- Production support
Over time
The work changes with the product.
Some changes sit in the visible workflow: event setup, bidding and donations, payments, messages, reporting. Others sit underneath it: dependencies, integrations, email delivery, infrastructure, and operational support.
The common thread is not a single technology. It is understanding which behaviour users and operators already rely on, then changing the right layer without destabilizing the rest.
The relationship continued beyond the initial build through maintenance, staged releases, infrastructure work and production support.
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.
What this kind of work requires
- Understand the product before changing it.
- Work safely inside an established system instead of defaulting to a rewrite.
- Connect operating rules to product behaviour, architecture, and implementation.
- Evolve integrations and infrastructure without losing the workflow around them.
- Treat maintenance and production support as product engineering.