Behind most hesitation about custom software is one question: what if it doesn't work?
Not "what if the code has bugs." Everyone expects that. The real fear is bigger. What if we spend the money and the thing doesn't fit how we work? What if our data is messier than anyone thought? What if staff won't use it? One staff lead at a trade association, looking back on the decision to hire us, said the worry was simply that they'd hire someone and then discover it couldn't be done.
You can't argue that fear away. You can make it cheap to test.
The Case for Tiny
A small first piece is not a smaller version of the whole project. It is a different kind of thing: an experiment designed to answer the questions that would otherwise be answered at the most expensive possible moment.
A tiny first piece:
- Costs little if it fails. The loss is capped at the size of the experiment.
- Surfaces the real data. Every organization's data is messier than its owners think. Five real records teach more than fifty pages of specification.
- Tests the working relationship. You learn how the builder estimates, communicates and handles surprises. They learn how quickly you can answer questions.
- Gets a real result into someone's hands. Reactions to working software are more honest and more useful than reactions to a description of it.
This is the pattern we see work most consistently, with new clients and with clients we've worked with for years. Each piece is estimated and approved before it starts, and the first one is often a pilot on a handful of records.
What "Tiny" Actually Means
Tiny is smaller than most people's first instinct. Some shapes it takes:
- Five records. Run the new process on five real cases, checked by hand, before running it on five thousand.
- Five users. For a member-facing change at CXPA, the suggestion was to test with a sub-segment of users, a select five, before rolling out to everyone.
- One template, one product, one form. Build the pattern once, prove it, then apply it to the rest. As we put it to an apparel brand: address it on one, then take those lessons and apply them to the rest.
- One step of a longer process. Automate the step that eats the most time, and leave the rest manual for now.
A good test for size: could you describe what the first piece does in one sentence, and could you check every one of its results by hand?
What the Pilot Tells You
A pilot is only useful if you decide in advance what you're looking for. Before it runs, write down the questions:
- Does the output match what a person would have produced? Compare every record.
- What share of cases did it handle cleanly? The rest are your exceptions, and their volume matters.
- What surprised us about the data? Duplicates, missing fields, formats nobody mentioned.
- Did the people who'll use it actually use it? Or did they route around it?
- Was the estimate right? If it was badly off for a small piece, find out why before approving a large one.
Then decide: expand, adjust, or stop. All three are good outcomes. Stopping after a small pilot is a far better result than stopping halfway through a large build.
"We Need to Get Some Usage First"
One founder said this about a feature he'd been asked to build out further, and it is the best short argument for starting small.
Until something is in use, every opinion about it is a guess, including the builder's. Which fields matter, which screens get ignored, what people ask for next: you only find out by watching real use. Building the second piece before the first has been used means building on guesses.
A franchise company that had been burned before landed in the same place during scoping. When we suggested starting small and expanding from there, the reply was: "let's start small like you said and we can use that as like a proof of concept."
Small Pieces on a Big Project
Starting small is not only for small projects. It matters most on large ones.
One nonprofit client reached the point where its platform needed substantial rebuilding. Their product manager said what everyone was thinking: "We all know that this is going to be a big project." A big project doesn't have to be one big commitment, though. We phased the work and kept the existing records working throughout, because the worst outcome would be getting halfway through and discovering the new work wasn't compatible with what was already there. After hearing that plan, the product manager said: "Great. I feel better about it already."
Work on a platform that size is exactly where one large, all-at-once commitment is most dangerous.
The Objections to Starting Small
"It'll cost more overall." Sometimes marginally, because there's overhead in each piece. That overhead buys the ability to change direction, which almost every project needs. The expensive outcome is building the wrong thing completely.
"We need the whole thing by a deadline." Then the first piece matters even more, because a problem found in week two can still be fixed. The same problem found in month four threatens the deadline.
"Our process is too interconnected to split." Almost no process is. There is nearly always a step, a record type or a group of users that can go first. Finding it is part of scoping.
"The small version won't impress anyone." It isn't meant to. It's meant to work, which is more persuasive to a board than a demo.
When Tiny Is Too Tiny
There is a floor. A first piece should still deliver something real: a result someone actually uses, on real data, in the real environment. A prototype that runs on made-up data in a test account answers very few of the questions above. Keep it small, but keep it real.
For how to decide what belongs in a first build at all, see How to Scope a First Custom Build Without Over-Building.
A Simple Rule of Thumb
Make the first piece small enough that you'd be comfortable if it were the only piece.
If it works, you've lost nothing by starting there. If it doesn't, you've found out for the price of the smallest possible experiment.
Final Thoughts
"What if it doesn't work?" is the right question to ask about any custom build. The answer isn't a promise from the builder. It's a first piece small enough that you can find out for yourself, cheaply, before committing to the rest.
If you have a project in mind and want to work out what the smallest useful first piece would be, we're happy to help you find it. See how we approach custom software, or book a short consult.