Software product development for companies whose product is now the business.
Engineering that treats your product as something you keep, with the decisions about scope, quality and ownership made deliberately.
Building and running software since 2007Source in your repository, with history intact
- Made deliberately
- Made by accident
Illustrative of the shape, not a measured figure. No change-cost curve from an engagement is published.
Three ways product engineering quietly stops working.
Product engineering is the wrong frame if you need one internal tool built once. That is custom software development. This page is for software you intend to keep selling and keep changing.
Every release is a negotiation
Features ship, but each one takes longer than the last, and nobody can say which decision made that true.
The roadmap and the codebase disagree
What the business wants to sell next is the thing the architecture makes hardest.
Quality is a phase, not a property
Testing happens at the end, so the cost of a defect is discovered at the most expensive point.
What we take on.
Six kinds of work on the same product, tagged by the part of it each one touches rather than by the activity that produces it.
Product engineering teams
TeamSenior engineers working on your product continuously, rather than delivering a project and leaving.
Architecture that follows the roadmap
ArchitectureStructure chosen against what you intend to sell next, not only against what exists now.
Release and quality engineering
ReleaseAutomated testing, release paths and rollback built as product properties rather than end-of-project tasks.
Platform and multi-tenancy
PlatformWhere one product must serve many customers with separated data and configurable behaviour.
Performance and scale work
ScaleWhere the product works and the growth curve is now the constraint.
AI features inside the product
AI featuresBuilt with the evaluation and controls covered on MLOps and LLMOps, not bolted on at the end.
Where this page stops.
A first version in thirty days belongs to Moonship MVP. One-off internal systems belong to custom software development. Changing software you already run belongs to system modernisation.
The four decisions that set what your product costs to change.
Product velocity two years out is decided by four choices made early, usually without anyone naming them as choices.
How much of the product is configurable
The cheap answer nowHard-code the behaviour each customer asked for
What it costs laterEvery new customer is an engineering change rather than a setting
When the cheap answer is rightFewer than a handful of customers, and no plan to add many
Where the tests are
The cheap answer nowManual checking before release
What it costs laterRelease confidence falls as the product grows, so releases get slower
When the cheap answer is rightA product still finding its shape, where the tests would be rewritten weekly
Whether the data model matches the domain
The cheap answer nowModel what the first screen needed
What it costs laterEvery later feature works around the original shape
When the cheap answer is rightGenuinely never, though it is the most common shortcut taken
Who can deploy
The cheap answer nowOne person who knows the process
What it costs laterRelease cadence is limited by one calendar and one holiday
When the cheap answer is rightA team of two or three, briefly
We put these four on the table at the start of an engagement rather than discovering them in the third quarter. Two of them have legitimate cheap answers; two rarely do.
How a product engagement runs.
Six steps in order. The four decisions are answered second, in writing, rather than discovered in the third quarter.
Read the roadmap before the codebase
What you intend to sell next determines which parts of the current structure matter.
Answer the four decisions explicitly
Written down, with the reason, so a later change of mind is visible rather than accidental.
Ship something real early
A change in production in your normal release path, which tests the process as well as the code.
Build tests where defects cost most
Coverage weighted to the paths whose failure reaches a customer, rather than spread evenly.
Make release routine
Because a product that ships weekly and one that ships quarterly are different businesses.
Grow your team, not our headcount
Working sessions and shared ownership, so capability stays after the engagement ends.
Products we built that are still being sold.
Those figures describe those engagements and are not projections.
- Faster product-question response. Conscious Chemist. Product work against the brand's own data.
- 38%Faster product-question response. Conscious Chemist. Product work against the brand's own data.
- Faster trip acceptances. Milo. Operational product in a live fleet workflow.
- 30%Faster trip acceptances. Milo. Operational product in a live fleet workflow.
- Building software since
- 2007Building software since
- Projects delivered
- 500+Projects delivered
- Longest running client integration
- 9 yrsLongest running client integration
- Countries served
- 6Countries served
For product work the nine-year integration is the more relevant number: it is evidence that what we build stays sellable.
See all case studiesWhere product engagements usually start.
Relevant published case-study routes cover beauty and personal care, consumer health, fleet and workplace operations.
A product that outgrew its first team
Where the people who built it have moved on and velocity went with them.
A roadmap the architecture will not allow
Where the next three things to sell all require the same structural change.
Every customer needing a code change
Where configurability was deferred and each sale now costs engineering time.
A release cadence nobody defends
Where shipping is quarterly because it always has been.
What a product costs to own, beyond the people building it.
We raise these at the four-decisions stage because each one changes what is worth building.
Dependencies age on their own schedule
Frameworks and libraries need upgrading whether or not the product changed, and deferred upgrades compound into a rewrite.
Every customer configuration is a supported path
Flexibility sold is flexibility maintained. That is a running cost decided at design time.
Support load follows product decisions
A confusing flow becomes tickets. The cheapest support saving is usually a design change.
Old versions do not retire themselves
Customers stay on what works for them, so supporting several releases at once is a choice made by default.
An engineering partner, a hired team, or engineers alongside yours.
Three ways to resource the same work, each one readable on its own, including what it leaves behind when it ends.
A partner team
Fits whenYou need capability now and continuity matters more than headcount
Speed to startFast. A team already exists
What it risksDependency, if no one internal owns the product
What it leavesSoftware plus whatever handover you insisted on
Hiring in-house
Fits whenProduct is permanently core and the work never ends
Speed to startSlow. Hiring rarely matches the roadmap
What it risksHiring for a phase and keeping the cost after it
What it leavesPermanent capability at permanent cost
Engineers alongside yours
Fits whenYou have a team that is too small or missing specific experience
Speed to startFast, and it scales down without a redundancy conversation
What it risksBlurred ownership without a named internal lead
What it leavesSoftware plus your team having built it with us
We have an obvious interest in the first and third columns. The honest test is whether someone internal will own the product, and if the answer is nobody, none of the three works.
What you have as the engagement runs.
Each of these exists while the work is running rather than being assembled at the end of it.
Source in your repository
Owned and readable, with history intact.
The four decisions, written down
With the reasoning, so a later reversal is deliberate.
Tests on the paths that matter
Weighted to where defects reach customers.
A release process your team runs
Deploy and rollback documented and exercised by your engineers.
A written list of deferred scope
What was not built and why, so the next decision starts from the record.
Who we need from your side.
Four people rather than four job titles. Each one holds an answer the four decisions need.
Continuity on your side is the one input we cannot supply.
Someone who owns the roadmap
The four decisions cannot be made without knowing what you intend to sell next.
Whoever supports the product today
The support queue is the most accurate list of what is wrong with it.
An engineer who will stay
Continuity on your side is what makes this a partnership rather than an outsourcing arrangement.
Someone who can decide on quality spend
Because test coverage and configurability are commercial decisions, not technical ones.
How access and code ownership are handled.
We do not claim a certification we have not been audited against. These four are agreed in writing before work starts.
Your repository, your review process
We work through your pull requests, so every change is reviewed by your team before it lands.
Least access, granted per need
Access to production and customer data scoped to what a task requires rather than granted by default.
Your secret store
Credentials stay where your team already keeps them, and are never copied into documents or chat.
Access ends when the work does
Removal is part of the engagement rather than something to chase afterwards.
How we work inside a team that already exists.
Most product engagements join a team rather than replacing one, and the failure mode is two groups building in parallel.
Who reviews what
How it is set
Your engineers review our changes and ours review theirs, from the first week.
What it preventsA codebase with two styles and no shared understanding of it
Who is on call
How it is set
Your rotation stays yours. We are reachable but not the first responder.
What it preventsAn operational dependency that outlasts the engagement
Who decides architecture
How it is set
Your lead, with our recommendation in writing.
What it preventsStructural decisions made by whoever happened to be in the code that week
What we do not touch
How it is set
Named at the start, usually the parts your team is actively reshaping.
What it preventsTwo people rewriting the same thing in different directions
What teams ask before they start.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.
Tell us what you intend to sell next year.
Product decisions are easier to judge against a roadmap than a codebase. Describe what you want to be selling in twelve months and we will name what is in the way.