A prototype before the contract: what you see and why it saves you money

Most software projects start with a document. The document matters, and I write a spec in Arabic for my projects that the client checks line by line. But a document on its own leaves a gap. What a reader pictures from a line can be quite different from what the writer meant.

That's why, when a project is a good fit, I prepare a clickable prototype before the contract. Here I explain what it is, what it isn't, and why it saves you money and time.

Why a written spec alone isn't enough

Take a typical line from the spec for an operations system: "The manager can follow up on late orders." The line is clear, and nobody objects to it. But once building starts, questions come up that no one asked:

• When does an order count as late: after the agreed delivery date, or after a set time since it was created?
• Does the manager see only his team's orders, or the whole company's?
• Does he want a list, a number at the top of the screen, or an alert on his phone?
• What does he do once he sees a late order: reassign it, add a note, or call the employee?

The spec doesn't answer these because nobody has thought about them yet. People rarely think about them while reading text. They think about them when they see a screen and try to use it.

Each of these questions has more than one right answer. The problem is when the developer picks the answer alone, and you discover the choice after it's built.

What the prototype is

The prototype is a set of clickable screens built around the way your company works. It has your department names, the stages an order goes through in your company, and sample data that resembles what you deal with day to day.

• Your system's screens. You open it on your phone or computer and move between screens as you would in the real system.
• Sample data. Made-up orders, customers and figures, enough to show what a screen looks like on a normal working day.
• Within days. I prepare it within days of the discovery calls and the written spec.
• A walkthrough video. I include a video where I go through the screens step by step. You can forward it to your warehouse manager or accountant for their opinion, even if they weren't in any meeting.
• Free when the project is a good fit. You pay nothing to see the prototype, and it doesn't commit you to anything.

What the prototype is not

So expectations are clear from the start:

• It doesn't store real data. Nothing you enter is saved, and the numbers in it aren't yours.
• It isn't the finished system. It has no integrations with your platforms, no permissions, and none of the logic that runs behind the screens.
• It isn't the final design. Colors and small details may change. What matters at this stage is the flow: what the user sees, what they do, and where they go next.
• It doesn't mean the project is nearly done. The screens look real, but most of the work sits behind them: data, integrations, permissions, reports and testing.

That last point matters. A good prototype is convincing, and it can give the impression that the system is almost finished. In fact it's a tool for agreeing on what will be built. It isn't part of the build.

Why it saves you money

Changing a screen in the prototype is quick and cheap. Changing the same thing after it's been built in code is slower and much more expensive, because in the real system that screen is tied to the database, permissions, reports and integrations with other platforms. One change can touch many parts.

A change on a screen is cheap. The same change in code is expensive.

Here are the kinds of comments that typically come up when reviewing prototypes of operations systems. They aren't from any specific project:

• The operations manager notices an order needs an approval step nobody mentioned in the spec.
• The accountant asks for an extra field on the invoice so it matches what they use today.
• Whoever will use the app in the field says the screen is too crowded on a phone.
• Management realizes a feature it asked for at the start isn't actually needed.

That last one deserves a pause. Dropping a feature before it's priced costs nothing. Dropping it after it's built means you've already paid for it.

There's a less obvious benefit too. When several people from your company look at the same screens, the differences between them surface early. The manager may picture one flow for an order while the warehouse works another way. Settling that in front of the prototype is far easier than after the system has been built around one of them.

The prototype helps me too. Once the screens are agreed, there's less ambiguity, so I can price the project more accurately, and both sides face fewer surprises during the build.

How to review the prototype

To get the most out of it:

1. Watch the video first, so you know the flow the screens were built around.
2. Open the prototype on your phone and think of a real order from yesterday: how it arrived, who picked it up, when it was closed. Try walking it through the screens.
3. Send it to the people who will actually use the system, not only to management.
4. Write your comments next to the name of the screen they refer to, so nothing gets lost.
5. Focus on the flow and the information before colors and fonts.

What happens after the prototype

After you review the prototype, I update the written spec to reflect what was agreed. Then I send an offer priced item by item: each item has its own price and duration, and you can remove or postpone any of them.

Once you approve, the build starts in releases, on a staging environment that you test yourselves with data closer to the real thing. I don't move to the next release until you've approved the previous one. The code repository and all accounts are in your company's name from day one.

And if, after seeing the prototype, you decide not to go ahead, that's a normal decision with nothing owed. In that case the prototype has done its job: it helped you reach a clear decision before committing a budget.

A checklist before you sign

Answer yes or no about the project you have in mind:

• Have you seen your system's screens before signing the contract?
• Have the people who will use the system tried those screens?
• Do you know what happens to an order from the moment it arrives until it's closed?
• Do you know who sees what in the system?
• Have you seen how the screens look on a phone?
• Have you removed what you don't need before it was priced?
• Do you know what the prototype includes and what it doesn't?

If many of your answers are "no", part of the project probably still lives in people's heads and hasn't reached paper or a screen yet.

If it helps, describe how your process runs today and what you'd like to change, and I'll tell you what a first prototype of it might look like.

Related to this articleDemos