How to pick the first thing you build

The hardest part is starting, and the thing that makes starting hard is almost never technical. It is that the first build gets chosen for its size. Somebody asks what the biggest cost in the business is, points at it, and now the first thing anyone here has ever built has to be the thing the company cannot run without.

We have had this conversation with more than a hundred companies over the last six months. The ones who got somewhere in a quarter all did roughly the same thing, and it was smaller than what they came in asking for.

01Start with something you were going to buy anyway

Software you had budget for and had not bought yet is the cleanest place to build. There is nothing to unpick, no integrations to preserve, no migration, and nobody has ten years of habits built around the thing you are replacing, because there is no thing you are replacing. A build and a purchase get to compete on even ground, which is the only way anyone learns anything from the comparison.

The agricultural commodities business in Build vs buy was weeks away from signing for document comparison software at several hundred thousand dollars a year. That is the ideal starting position and most companies have one sitting in a budget line right now.

Replacing an application you already run is harder. Something is already there holding data people depend on, and the build has to be at least as good as a tool that has had years of polish before anyone will move. That is a second or third project, not a first one.

02What makes a good candidate

Four tests. A first build that passes all four is worth starting this month.

1. One owner. One person whose job gets better, who can say what correct looks like, and who can be wrong about it without a meeting. Two departments sharing a first build means a committee, and a committee cannot answer questions at the speed a build asks them.
2. The work is already written down. A checklist, a template, a document somebody follows, a spreadsheet somebody maintains. If the process only lives in one person's head, the first month goes into finding out what the process is, and you learn nothing about building.
3. A human still signs off. The first build should put a person in front of the output, not behind it. That is what makes it safe to ship in six weeks, and it is also the thing that makes the team trust it, because they can see what it got right before they stop checking.
4. Bounded. One workflow, one desk, one output. Not a platform. The platform is what you get after four of these, and it is much better than the platform you would have designed up front.

03What to keep away from first

Your system of record. Anything with a data migration in it. Anything where the current process is undocumented and contested. Anything that has to be right on day one with no human in the loop, which usually means anything that moves money without a person looking at it.

None of these are permanently off limits. They are just the wrong thing to learn on, and the cost of learning on them is that the organisation concludes this does not work.

04What the first quarter looks like

A first working version in four to six weeks. A hardened production version in a quarter. Those are our numbers on real builds and they hold when the scope holds.

What happens inside them is worth knowing, because it does not look like a software project. The first version is wrong in the details and right in the shape, which is the useful direction to be wrong in. The people who use it correct it, and those corrections are the requirements. Nobody could have written them down in advance, which is why the document that would have taken six weeks to write was never going to be worth it.

If what you are looking at is very large, break it into two or three pieces and build the first one. A CRM or ERP implementation running into a year is completely routine and nobody calls that slow, so a quarter for something that works is not the risk it sounds like.

05How to know it worked

Not by whether the tool is good. By whether a second one starts.

The real output of a first build is that somebody in the business who is not an engineer has now watched a thing they described turn into software, and they have opinions about the next one. In Going hybrid that is the whole mechanism: sales, HR, finance and recruiting open their own branches, an agent gets them most of the way in twenty minutes, and what comes back has the details wrong and the shape right.

That does not happen off a project plan. It happens after the first build ships and somebody sees it.

06FAQ

How small is too small?

If it takes a week and nobody outside the team notices, it taught you nothing about your organisation, which is most of what a first build is for. Aim for something one desk uses every day.

Do we need to hire engineers first?

No, and hiring before the first build is how companies spend a quarter on recruiting instead of shipping. A lean team builds the first one. The hiring question gets much easier to answer once there is something running, because you know what you are hiring for.

What if the first build fails?

Then it cost four to six weeks and you know considerably more about your own processes than you did. That is the reason the first one should not be the thing the company cannot run without.

Tarush