Build and launch

Your situation already names the build work

Something about this build is fixed and is not yours to move. Name that, and which of seven kinds of software build this is stops being a matter of opinion.

The week you have just had

You have decided to build. You have told somebody with authority that it is happening. Since then you have had three conversations, and each one renamed the thing to whatever the firm across the table sells. One called it an MVP, another a platform, the third a replatform. Every explanation was convincing on its own.

You came out of the week less able to say what this is than when you went in. Weeks of planning, no clear roadmap, and a lot of talk about tools and stacks. Very little about what you are trying to reach. The hard part is what to call it, and so far nobody has helped with that.

Start from what cannot move

You already hold the fact that decides this. It is the thing in your situation that nobody involved can move: a date somebody else booked, customers already paying, a person who is blocked, or the absence of a figure you can defend. Say that one out loud, and the shape of the work follows from it rather than from whoever you spoke to last. That is the whole method, and it works in the next vendor call as well as here.

Two ways to name the work

The catalogue route asks you to learn seven definitions first. Naming from your fixed constraint needs a fact you already hold.

How the work gets named, two starting points compared
From the catalogueFrom the fixed thing
Where you startWith seven service names and their definitionsWith the one thing nobody involved can move
What you learn firstThe vocabulary, before any of it applies to youNothing new, because the deciding fact is already yours
When two people disagreeWhoever explains their category most convincinglyA date, paying customers, or a blocked person
When you find outthe expensive partAfter the build, when the shape stops fittingBefore anything is committed, in one sitting

Three situations that belong somewhere else

We have declined engagements where taking them would have benefited us but not the project. We are success partners. If we are not the right team for what you are building, we will tell you that.

Where we fit here

  • You are building something new, or replacing something that no longer carries what the business now needs from it.

  • You have made a commitment to somebody senior and now have to name the work sitting behind it.

  • You can point at one fact about your situation that nobody involved is able to change.

Where to go instead

Two ways a wrong shape fails

Suppose the shape you pick is wrong. Would it be wrong as too small for something the business ends up running on, or too large for something nobody has confirmed yet?

  • Bought too small

    Choose this when

    You scoped a version to prove one thing, and within months the business is running on it.

    It costs you

    Less of it was written down, because that was not what it was for. It fails as an outage rather than a missing feature, and the fix competes with everything else you owe.

  • Bought too large

    Choose this when

    You are building against a fixed date, for demand that nobody has yet confirmed with money.

    It costs you

    The schedule runs on reasoning about behaviour you have not seen. You reach the date with more built than anyone asked for, and the part that mattered arrives last.

Which kind of build is yours

Find the one thing in your situation that is already fixed and cannot be moved. The set it sits under holds the work, and the link under that holds the detail.

A date is fixed

Somebody outside the project has already committed to it.

Already carrying load

Real customers depend on it today.

The software has to be bent

A packaged product would have to be configured around the work.

A person is blocked

Routine changes wait on one individual.

Shipped through a store

The delivery target is an app store, not a URL.

No number yet

The figure has to come before the build.

What happens after you pick

  1. 01

    First call

    A shared read of your situation. You bring no specification and no view on the stack, because stack selection is part of scope.

    You get

    A written summary of what you said and what we heard the shape to be.

  2. 02

    Scope

    The shape of the work, and the stack decision with its reasoning. In most cases refining continues alongside the build.

    You get

    A scope statement naming what is in, what is out, and what it depends on.

  3. 03

    Build

    Work runs against that scope, and you see the thing itself rather than a status update about it.

    You get

    Working software you can open and try, at every point where something is finished.

  4. 04

    Changes

    A written change note, agreed before anything moves. Nothing in the build moves on a re-scope you have not explicitly accepted.

    You get

    A change note you accept in writing. Nothing in the build moves on a re-scope you have not accepted.

One thing you can check before anything else

Open any of the seven above. Each one tells you early who it is wrong for, and where those people should go instead. Do that before you speak to anybody here, and ask whoever else is bidding for the same work to show you theirs in the same form.

  • Each one names who it is wrong for, early
  • Each one says plainly what it will not do
  • Each one points you at a better route, not back here
  • Each one is readable in full before you contact anybody

Questions before you pick

The practical ones, answered here so you do not have to ask them twice.

Do I need a full specification or finished designs first?
No. You do not need either to start, and you do not need to arrive with a view on the stack. How much has to be settled in writing before the work itself begins depends on how the engagement is set up, and you will know which applies to yours before anything starts. Bring the situation and the commitment you have already made. Whatever exists in writing helps, even one paragraph in an email. Writing the specification is part of the work here rather than something you have to arrive holding. If you arrive with mockups, we work from those. We do that before anything is built against them.
What if I have no view on the stack or architecture?
That costs you nothing. Choosing the stack is part of scope. You do not need a technical opinion at the first call. The constraints matter more than a preference. Two things help most: what this has to talk to, and what your team must be able to maintain. Hosting rules from your side belong there too.
Do you build new products, or improve ones that already exist?
Both. We improve what already exists and we rebuild from the ground up, and we welcome both. Which one fits comes out of looking at what you have and what it has to do next, rather than out of a preference of ours.
What happens if I need more after we start?
It goes through a written change note, agreed before anything moves. Nothing in the build moves on a re-scope you have not explicitly accepted. That runs in both directions. A change you want is written down with what it affects, before work shifts to it. Anything we think is needed arrives the same way, in writing, for you to accept or refuse.
Do you only work with startups?
No. The work runs from first products for founders through to systems inside established organisations. The shape is decided by the situation rather than by the size of the company. What differs is who has to be convinced internally, and what the thing has to connect to on day one. Both are part of scope rather than surprises later.
Can I talk to a real person before committing to anything?
Yes, and it is a short first call, roughly fifteen to forty-five minutes. You describe the situation. We say which shape of work it looks like, including when that is none of ours. A senior software engineer can join that call on request. Ask if there is something technical you want tested first.