Services
Software Engineering
Architecture, subscription platforms and data pipelines — built to be maintained.
What you get
- Product and system architecture with the tradeoffs written down
- Subscription and billing platform design, including entitlements and churn handling
- Data pipelines, ETL, and reporting infrastructure
- API design, integration and third-party system automation
- Code review, refactoring and rescue of inherited codebases
- Technical due diligence and second-opinion architecture reviews
Outcomes
- A system your team can extend without fear
- Deploys that are routine instead of events
- Data you can trust in the reports leadership reads
- Documented decisions, so the reasoning survives staff turnover
Capabilities
Product and software architecture
System design from first principles or a rescue of something that grew organically. Explicit about constraints, cost and what we are deliberately not optimising for.
Subscription and membership platforms
Billing, entitlements, trials, upgrades, dunning, cancellation flows and revenue reporting. Built from running a real subscription business at scale, not from a tutorial.
Data pipelines and reporting
Ingestion from SFTP, APIs and third-party feeds, transformation, validation, and reporting your finance team can rely on. With alerting when a feed goes quiet.
API design and integration
Clean interfaces, sensible versioning, and integration with the systems you already pay for, including the ones with unpleasant APIs.
Codebase rescue and refactoring
Inherited a system nobody understands? We map it, stabilise it, add tests around the dangerous parts, and make it safe to change.
Technical due diligence
An independent read on architecture, security, scalability and technical debt before you invest, acquire, or commit to a rebuild.
Engineering that expects to be inherited
Every system is eventually maintained by someone who was not there when it was built. That fact should shape how it is written.
So the standard we hold is simple: could a competent engineer who has never seen this code understand why it is shaped this way, from the code and the documentation alone? If not, it is not finished.
Where we are most useful
Systems that outgrew their design. Something built quickly, that worked, that the business then grew into. Now every change is risky and nobody wants to touch the billing logic. We stabilise these — map, instrument, test, then refactor.
Subscription and membership platforms. Recurring revenue systems have a specific cluster of hard problems: entitlements that must be exactly right, trials and upgrades and downgrades, failed payment recovery, cancellation flows, and revenue reporting that reconciles. We have built and operated these.
Data pipelines. Ingestion from SFTP drops, vendor APIs and third-party feeds, through validation and transformation, into reporting that finance and leadership actually use. The engineering challenge is rarely the happy path — it is what happens when a feed arrives late, malformed, or silently stops.
Second opinions. An independent architecture or due-diligence review before a significant commitment. No stake in the outcome, no rebuild to sell you.
Operating principles
- Boring technology by default. Novelty is a cost paid by whoever maintains it.
- Observability before optimisation. Measure, then change. Most performance intuitions are wrong.
- Security is structural. Input validation, least privilege, secrets handling and dependency hygiene are part of writing the feature, not a later audit.
- Decisions get written down. Not just what was built — why, and what was rejected.
- Reversibility. Every deploy should have an obvious way back.
Background
Twenty-five-plus years spanning aerospace certification engineering — where documented compliance is the deliverable and “it seems to work” carries no weight — and financial technology, where a subscription platform and its data pipelines have to be right every day, in public, for paying customers.
Both environments produce the same habit: assume it will fail, decide now what happens when it does.
Frequently asked questions
We inherited a codebase and are afraid to touch it. Can you help?
This is a large share of what we do. The sequence is: map what exists, instrument it so behaviour is observable, add characterisation tests around the parts that would hurt most if they broke, then refactor behind that safety net. Rewrites are a last resort, not a first instinct.
Should we rewrite or refactor?
Refactor, in most cases. Rewrites routinely take longer than estimated, and during the rewrite you are maintaining two systems while shipping no new value. We recommend a rewrite only when the existing architecture genuinely cannot support a required capability, and we will show our reasoning rather than assert it.
Do you work with our existing development team?
Yes, and that is usually the better arrangement. We come in as a senior engineer alongside your team, transfer the reasoning as we go, and leave documentation behind. The goal is that your team is more capable afterwards, not more dependent.
What is your experience with subscription businesses?
Direct and ongoing. Subscription platform work covering billing, entitlements, trials, churn analysis and revenue reporting, alongside the data pipelines and operational alerting that keep a subscription business honest about its own numbers.
What stack do you work in?
Primarily PHP, Python, JavaScript and TypeScript, with PostgreSQL, MySQL and Redis. Plus the infrastructure around them. We choose boring, well-supported technology unless there is a specific reason not to, because you have to maintain it after we leave.
Related services
Infrastructure & Backup
Servers, clusters and backups designed so that failure is survivable and boring.
Learn moreAI & Automation
AI wired into the work you already do, with the security questions answered first.
Learn moreWordPress Development
Custom builds, hardening, and cleanup for sites that have been hacked or abandoned.
Learn moreTell us what is breaking — or what you are trying to build.
You get a senior engineer on the first call, not a salesperson. If we are not the right fit, we will say so and point you somewhere better.
Active incident? Write “URGENT” in your message and we prioritise it.