How a Software Project Works, Step by Step

You've decided the ledger book and the Excel files have to go. You have a rough picture of what the new system should do, and a number in your head for what you'd like to spend. What you don't have is any idea what happens after you send that first email to a software builder. Will they disappear for a long stretch and return with something you never asked for? Will they ask questions you can't answer? Nobody explains this part, and not knowing it is what makes a lot of owners put the decision off for another year.

This post walks through how a software project works from the owner's side of the table: six steps, what you do in each, and what you should be holding when each one ends. We're a software agency, so this is how we run our own projects. Other builders run theirs differently, and that's fine. Use these steps as a checklist for comparing them, and don't take our word for any of it until you've seen it in writing.

How a software project works, in six steps

Here's the whole path in a few lines, so the rest makes sense. It starts with a discovery call, then a written proposal, then a plan for how the pieces fit together before anyone writes code. After that the software is built in short stretches, with a demo of the work along the way. It then launches on accounts you own, and a support window follows for whatever real use turns up. People in the trade call this the software development process. You can think of it as talk, agree, plan, build, launch, look after.

Your part in all of it is to be the expert on your business. You don't need to know anything about software, and nobody should make you feel awkward or behind for that. What we need from you is honesty about how the work really gets done, including the messy parts, because the messy parts are exactly what the software has to cope with. Throughout this post we'll picture a family-run shop whose orders and dues live in a ledger and on one relative's phone, so the steps have something to hang on.

What happens on the discovery call?

The first step is a discovery call about what you're doing, who it's for, and what you're up against, whether that's a deadline or a tight budget. Rough is fine. Nobody expects a technical document from you, and a description of how an ordinary Tuesday goes in your business is more useful than any document. The shop owner would tell us how an order arrives, who writes it down, where it goes wrong, and what they've already tried. On our side, we explain what we're hearing on a shared online scratchpad, a whiteboard-style page we can both see, so you can say "no, that's not how it works" while it's still a drawing.

You should leave this call with your questions answered and a clear idea of what comes next, not with a price. We don't quote before we understand the project, and that can feel like stalling. But a figure given before anyone has asked how your business runs is a guess, and you're the one who pays for a wrong guess. We'd also give both sides the same advice about this call: treat it as seriously as anything later. Whatever gets misunderstood here is cheap to fix now and expensive to fix once the building has started.

Reading a written proposal: what to look for

After the call you get a written proposal, and what's in it depends on how clear the project already is. When it's clear what needs building, you receive a statement of work, called a SOW for short. It's a document that spells out what will be built and what won't, with the timeline and the tools we'd use. When you're less sure what you need, which is true of many owners at this stage, we work in sprints instead. A sprint is a short, fixed stretch of work, and we plan the next few weeks together at a time. If you're unsure what a first version should even include, our page on building a first version is about that question.

Either way, you approve something in writing before any code is written, and it's worth reading slowly. The most useful part is the list of what's out of scope, because that's where a misunderstanding hides. If you expected the system to send reminders to your customers and the list says it won't, you want to find out on the page and not on launch day. The tools are the technology the software is built on, and it's fair to ask why each one is there and what it means for you. A good answer talks about your business, not about the tool. As for the price, it depends mainly on how many kinds of users the system has, how many other systems it has to connect to, how much of it is custom, and how much design work is involved.

Is there a plan before the coding starts?

Before the building starts, we plan how the system fits together and how its parts will talk to each other, and we sketch the screens where it matters. For the shop, that might be a rough drawing of the order screen: what you type in, and what the person packing the box sees. You don't have to follow the technical diagrams, but you should be able to read the sketches and say "we don't do it like that." This is the last cheap moment to change direction: a wrong turn caught on a sketch costs you a conversation, and caught after the building starts it costs you rework. Once you've approved the SOW or the sprint plan, that's our go-ahead to start building.

Why does the weekly demo matter?

Then the building begins, in short stretches, and you get to see it. On a full-time engagement we meet on a video call every week, and on part-time work every two weeks. Our founder joins that call, walks you through what has changed since last time, answers any doubts, and takes your feedback there and then. That feedback doesn't vanish. We talk it over internally and either build it or put it on the next call's list, and if something is blocking the work, we ask for a quick call in between instead of waiting. Between calls we stay in touch on a message channel you've agreed to, so the work doesn't stop because someone is waiting for an answer.

We feel strongly about one thing. The demo is the owner's job as much as ours. A project is more likely to go wrong in a demo where the owner nods politely than in the code. When you click through with your real routine and something feels off, say so in that moment, even if you can't explain why or you worry it's a silly point. "It feels slow" or "my staff won't work this way" is plenty for us to act on. And if a builder can't show you something working on a regular rhythm, ask them why before you pay for more.

Can I change my mind halfway through?

You will think of things you hadn't thought of, because nobody sees their own business clearly from outside until they've watched a version of it working. When a new requirement comes up, we work out how it fits against what's already built and see what has to be redone. Then we adjust the timeline, the budget, or both, and we tell you before going ahead. It's a conversation and a decision, not a surprise on an invoice.

We'll give you a real example, with the identifying details left out. Halfway through an internal portal for a factory owner, he told us he wanted something else. We had long discussions, and together we decided to restart the project. We reused as much of the finished work as we could, which saved us time, but the restart still cost more money and delayed his launch. Seeing something real on a screen changes what anyone thinks they need, and for him that moment simply came halfway through. The only thing that made it expensive was the timing, so we try to surface what's off as early as possible: on the discovery call, in the SOW, at every demo, and in the messages in between.

What do I get at launch?

At launch the software goes onto your own hosting, which is the online computer service that keeps it running, or we set that up for you. Either way the accounts are yours from day one, because we don't build on anything only we can get into. You receive the logins, a walkthrough and a training call so your team knows how to use it, and written technical documents for whoever looks after it later, whether that's us or somebody else. We also set up automated releases, which lets you publish updates on your own. If what you're building is a website, the first question is whether you need one at all, and our post on whether every business needs a websitecovers that.

Who looks after it once it's live?

Real use turns up things no demo does, which is why every project includes a post-launch support window, and our How We Work page says how long it lasts. Extending it is something we're happy to discuss. After that, most owners choose a monthly maintenance arrangement for bug fixes, keeping the building blocks the software is made from up to date, security patches, and small new features. Nobody is locked into a contract just to keep their own software running, and that's a real relief when you're not the technical one.

Who owns what when it's done?

You do. All the code, assets and intellectual property, meaning the legal rights to what's been made, belong to you once the project is complete and the final payment is made. The online accounts the software runs in are yours from the start, and signing an NDA, a confidentiality agreement, is standard before you share details. A simple test works for any builder you're considering: if they vanished tomorrow, could someone else pick up your project from what you hold? The same terms are set out in short on that page too.

How do I compare one builder with another?

Put the same few questions to every builder you're considering, including us. You're looking for plain answers, not impressive ones.

• Is there something in writing that you approve before building starts, with a list of what's left out?
• Will you see the work running on a regular rhythm, not only at the end?
• Are the accounts and the code yours, and is that written down?
• Is the support after launch stated up front, along with what it covers?
• Do they ask more about how your business runs than they tell you about their tools?

We sell software projects, so weigh our version of all this accordingly. A builder who runs things differently isn't wrong, but they should be able to explain how they cover the same ground. If the answers are vague, that tells you something before you've spent anything, and it's far better to feel a little awkward asking now than to feel stuck later.

If you'd like to know who would be running your project, our Aboutpage introduces the team. Our founding team leads every project from the discovery call to delivery, and stays your point of accountability throughout. Tell us roughly what you're building and we'll start with the conversation described above.