§ BUILD & DELIVERY

Custom Software Development

Delivery we own end to end — a fixed scope with a date where the work is known, time and materials on a rolling agile engagement where it is not. The same senior engineers stay on it from architecture through release.

Who
Delivered by a senior team assembled for the engagement, against a defined scope.
Request a call What this covers

What you're seeing

There is a defined build and your own team has no capacity to absorb it.
Usually means The work is competing with the product roadmap and losing every planning cycle. Adding it to the same backlog does not change the outcome, it just moves where the slippage is reported.
The architecture decisions matter more than the line count.
Usually means This is not a body-count problem. Work where the expensive mistakes happen in the first fortnight is badly served by an arrangement that optimises for the number of people available.
You know where you are going and not how you will get there.
Usually means The requirements will be rewritten as you learn, which makes a fixed scope the wrong instrument. It is a real and common situation, and it needs a rolling engagement rather than a re-estimation every month.
Two vendors are being compared and the comparison is on hourly rate.
Usually means The scope is not defined well enough for the rates to be comparable. Rate is only meaningful once both sides are quoting for the same result, and if they are not, the cheaper number is the more expensive project.
The last outsourced build arrived working and unmaintainable.
Usually means The engagement optimised for the delivery date and nothing enforced what came with it — tests, documentation, a deployment path your team can run. That is a contract design failure rather than an engineering one.

What you are buying

Delivery we own, on one of two commercial shapes.

Fixed scope. The scope is written down and carries a date. You buy the outcome, the sequence is ours to arrange, and the reporting is against what shipped rather than against who was busy.

Time and materials. A rolling engagement for work whose destination is clear and whose route is not. You buy the team’s time at an agreed rate, priorities move between sprints, and we still hold delivery rather than handing you a queue to manage.

Either shape puts the same senior engineers on it from architecture through release. Which one fits depends on how settled the requirements are, and it is a question worth answering honestly — a fixed price agreed over requirements nobody could pin down becomes a sequence of change orders, and a rolling engagement on work that was fully specified is a discount you gave away.

The line we hold

The distinction between managed delivery and staff augmentation is the whole business model, and it is invisible from the outside because the engineers are the same people.

Managed delivery: we own the scope and the result. Sequencing is ours to arrange, the standup we care about is our own, and the conversation with you is about what shipped and what is next.

Staff augmentation: you buy hours and manage them yourself, per person, day to day. That is a legitimate arrangement and several good companies sell it. It is not this one, and the reason is not snobbery — it is that the two get compared on hourly rate as though they were the same product, when one of them silently moves the management cost onto the buyer.

The practical test is who is accountable when something is late. If the answer is your engineering manager, you bought hours.

What comes with it

Three things are scope rather than goodwill, and they are why a quote here is larger than one that leaves them out.

A test suite that runs in your pipeline. Not written afterwards for completeness. Written alongside, because its actual job is to let the next person change the code safely, and that person is usually not us.

A deployment path your engineers run. If shipping requires someone from our side, we have sold you a dependency and called it a product.

Documentation for the parts that are not obvious. Not a description of the code — the decisions. Why this data store, why this boundary, what was considered and rejected. That is the part that is genuinely lost when a team changes.

The standard failure of outsourced delivery is a build that arrives working and unmaintainable, and it is a contract design failure rather than an engineering one: nothing in the agreement required the parts that only pay off after the final invoice.

The tiers stack

The strongest form is both at once: a Fractional CTO holding the engineering leadership seat while the delivery team executes underneath it.

Two of the four case studies took that shape, and neither market describes it. The fractional market sells a person and assumes a team exists. The agency market sells a team and assumes someone is directing it. What is actually being bought in both of those engagements was the seam between them — one party accountable for the technical decisions and for the delivery against them.

Two adjacent engagements are worth naming. Where the system exists and the problem is that it is fragile rather than incomplete, that is Platform Engineering. Where a build is one track inside a broader rebuild of how engineering operates ahead of a funding event, it runs under Delivery Implementation. Where the surface is a phone rather than a browser, the release path and the version tail are different enough to be their own scope: Mobile App Development.

What this covers

Each of these is a capability with its own page, its own order of work and its own outputs.

Capability What it means
Discovery Sprint A short, bounded piece of work that turns an intention into a scope both sides can hold. Cheaper than the first month of building the wrong thing, and it ends with a decision including the decision not to proceed.
Architecture Review An independent read on how the system is put together, where it will bend under the growth you are planning for, and what preventing that bend costs.
Backend & API Server-side systems and the interfaces other things depend on. Built with the contract written first, because an API is a promise and changing one after it has callers is expensive.
Web Development Web applications that stay fast and usable as they grow. Rendering strategy chosen against what the page actually needs, and accessibility treated as a requirement rather than a later audit.
Mobile Development Mobile applications where the release process is designed alongside the app. Store review, staged rollout and the long tail of OS versions are part of the engineering, not an afterthought.
Database & Data Modeling The schema the rest of the system is built on. Ownership, constraints and a migration path, decided before the model has a hundred callers and becomes expensive to change.
QA and Test Strategy A test suite people trust and run. Coverage placed where failure is expensive rather than spread evenly, and flakiness treated as a defect rather than as weather.
Release & Deployment Verification Deploying stops being an event. Changes go out behind flags, in stages, with the verification automated and a rollback path that has been tested rather than assumed.
DevOps Consulting Infrastructure described in code, environments that match each other, and a deployment path that does not depend on knowing who set it up.
AI App Development LLM features that hold up in production. An evaluation set before the feature ships, cost controlled by design, and data boundaries settled before a provider is chosen.
CRM & Product Integration Product usage and revenue systems agreeing about the same customer. Identity resolved, ownership per field decided, and reconciliation that reports what it could not match.
CI/CD Pipeline A pipeline fast enough that people wait for it. Build time is a delivery constraint, and a twenty-minute pipeline changes how a team batches work whether anyone intends it to or not.
Hiring Pipeline Design The path a candidate takes from first contact to signed offer, measured at every step. Most good candidates are lost to timing rather than to judgement.
Onboarding & Ramp-Up A new engineer productive in weeks rather than a quarter. A plan with named outcomes at thirty, sixty and ninety days, and an environment that works on the first morning.
Delivery Management Someone accountable for the date. Scope held, dependencies tracked, risks raised while there is still time to act on them — without adding a layer between the team and the work.

Next step

Describe the situation and we'll tell you whether this is the right shape.

Request a call

How we decide

  • We own the scope, not a seat

    Costs It rules out the arrangement many buyers arrive asking for, and it means saying no to revenue that would be easy to take.

    Managed delivery means the scope, the sequencing and the result are ours and you buy the outcome. Staff augmentation means you buy hours and manage them yourself. Same engineers, opposite accountability — and only one of the two produces a conversation about what shipped rather than about who was available.

  • Discovery before anything beyond a well-specified change

    Costs It delays the start by a couple of weeks and costs money before a line is written.

    A discovery sprint costs less than the first month of building the wrong thing, and it is where the scope becomes something both sides can actually hold. Skipping it is how a fixed-scope engagement turns into a sequence of change orders that nobody feels good about.

  • The code is in your repositories from the first commit

    Costs It gives up the leverage a handover event would create.

    There is no transfer, so there is no moment where a client is negotiating from a weak position. It also forces the work to be reviewable as it happens rather than presentable at the end, which changes what gets written.

  • Tests, deployment path and documentation are scope, not goodwill

    Costs They are visible line items, which makes the quote larger than one that omits them.

    A build that arrives working and unmaintainable is the standard failure of outsourced delivery, and it is not caused by bad engineers — it is caused by nothing in the contract requiring the parts that only pay off after the invoice. Naming them makes the comparison against a cheaper quote honest.

Managed delivery, augmentation, and hiring

Three ways to get software built by people who are not currently on your payroll. The difference is where accountability sits, and it is usually discovered late.

Arrangement Who owns the result Who manages the work What you have at the end
Managed delivery The supplier — the scope and the outcome are theirs The supplier, against an agreed scope or a rolling backlog The thing that was built, plus the tests and the deploy path to keep it
Staff augmentation You do Your managers, per person, day to day Whatever was produced, and the management overhead while it was
Hiring permanently You do You do, permanently The capability, after two to three quarters of hiring and ramp
A freelance individual Nominally them, practically you Mostly themselves Good work with a single point of failure attached to it

The first two rows are frequently quoted against each other and are not comparable. An hourly rate for augmentation and a price for an owned outcome answer different questions, and the second one includes the management cost the first one moves onto you.

Is this you?

  • A defined build that your own team has no capacity to absorb
  • A product where the architecture decisions matter more than the line count
  • Companies who want one party accountable for the result
  • Work whose destination is clear and whose route is not, where the scope will be rewritten as you learn

How we run it

We own the scope, not a seat

The distinction is the whole business model. Managed delivery means the scope and the result are ours and you buy the outcome. Staff augmentation means you buy hours and manage them yourself. Same engineers, opposite accountability, and only one of them is something we sell.

Frequently Asked Questions

Building software specifically for one organisation's requirements rather than configuring a product built for many. In practice the question that matters is not custom versus off-the-shelf but where the accountability sits: whether you are buying an outcome someone else owns, or hours you direct yourself. Those are different contracts with different risks.
Contractors take direction from your managers and their output becomes your management problem. Here the scope, the sequencing and the result are ours, and the standing conversation is about what shipped rather than about who was available. It is a different contract, a different price shape, and a different set of things that can go wrong.
It depends on how settled the requirements are, and we will say which we think it is on the first call. Fixed scope suits work where the destination and the route are both known — you buy the outcome and the date. Time and materials suits a rolling engagement where the route will be rewritten as you learn; you buy the team's time and we still hold delivery rather than handing you a queue.
Predominantly TypeScript, PHP and Laravel on the server, React and Next.js on the web, with Postgres underneath and the other stores chosen on access pattern rather than preference. Where a project's existing stack is different, we say honestly whether we should be the ones extending it.
For anything beyond a well-specified change, yes. A discovery sprint costs less than the first month of building the wrong thing, and it is where a scope becomes something either side can hold to. Where a client declines it, we price the risk rather than pretending it is absent.
You do, from the first commit, in your repositories. There is no handover event because there was never a transfer, and there is no point in the engagement where you are negotiating from a weak position about access to your own software.
Because the things that make it maintainable are in scope rather than in a promise: a test suite, a deployment path your engineers run, and documentation for the parts that are not obvious. That is also why a quote here is larger than one that omits them, and the comparison is worth making explicitly.
Either it ends, or it converts to a retainer for maintenance and the next tranche of work. We would rather name that at the start than let a project quietly become an indefinite one, which is the outcome that serves a supplier and nobody else.

Sources

Page reviewed