You Can’t Build Blind
The difficult part of starting something is often figuring out what, exactly, deserves to be built.
Have you ever noticed something that could work better and immediately started imagining how to fix it? Maybe an app that removes an irritating step, a device that makes a routine task easier, or a service that ought to exist but somehow doesn’t. Within minutes, the idea has features, a name, perhaps even a rough design.
That is one of the enjoyable parts of making things. An idea gives shape to an otherwise ordinary problem. It is tempting to open an editor, order components, or start sketching screens while the excitement is fresh.
But there is a peculiar risk in being able to build things: the tools are often ready before the questions are.
Consider a small repair shop that still books appointments by phone. It is easy to imagine the solution: a website where customers choose a time, receive confirmation, and never have to call. The interface almost designs itself.
Except the phone might not be the real problem.
Maybe the mechanic cannot promise appointment times because the duration of each repair is unpredictable. Maybe customers are less frustrated by calling than by not knowing what a repair will cost. Maybe a simple request form, followed by a human confirmation, would do more good than a sophisticated booking platform.
The first version of an idea usually contains a hidden assumption about what other people need. Finding that assumption is often more useful than developing the first feature
Look at what people already do
Before imagining how people will use something new, pay attention to how they get by without it. They may use another product, a spreadsheet, a message, an improvised workaround or rather simply tolerate the inconvenience.
Those alternatives are not irrelevant details. They are what a new idea would have to improve upon.
The most revealing conversations rarely begin with “Would you use this?” That question invites polite enthusiasm for something imaginary. Ask instead about the last time the difficulty occurred. What happened? What did the person try? Did it cost them an afternoon, a few dollars, or barely anything at all?
Get MXI.Studio’s stories in your inbox
Join Medium for free to get updates from this writer.
Sometimes the answers strengthen an idea. Sometimes they quietly dismantle it. Either outcome is useful while changing direction is still inexpensive.
The same curiosity needs to be outside of those discussions. Maybe it’s already included in a competing service. Maybe the technology is included in another product, but because of its cost or difficulty, it’s unattainable. Maybe the wrong audience is interested in the product after all.
A project does not need to be unprecedented to matter. A familiar solution made simpler, more accessible, or better suited to a particular group can be worthwhile. What matters is that the difference is meaningful to the people expected to choose it.
The part after it works
There is also a gap between making something work once and making it work reliably for others.
Prototype is a wonder on a desk. Product must hold up under the confusion, missing parts, failing updates, support inquiries, and costs long after initial fanfare. Device that you mean to sell might have safety and certification requirements. The service might rely on data, platforms, or permissions which you do not control.
These questions can seem premature when the project is still an idea. But discovering a critical obstacle early can change the entire shape of what is sensible to build.
Resources matter, too. Time spent making one thing is time unavailable for another. A personal automation that takes forty hours to create but saves ten minutes a week may still be a rewarding learning exercise. It simply has a different purpose from a tool intended to save time quickly. Both are legitimate projects; confusing their purposes leads to disappointing expectations.
This is where starting smaller becomes interesting. Instead of developing the entire booking system, a shop could test a basic form and confirm requests manually. Instead of building the finished device, test the difficult sensor first. Instead of committing to a full service, see whether a few people return after the first use.
A small test cannot answer every question. It can reveal which questions deserve a larger investment.
And at some point, the attractive idea in your head begins to look different. It gains boundaries. The audience becomes more specific. Some features disappear. An overlooked obstacle becomes central. What seemed like a grand product might turn into a modest tool that solves one problem exceptionally well.
That is not necessarily a loss of ambition. It is what happens when an idea begins to encounter the world it hopes to enter.
The next challenge is deciding what to build first, small enough to change, but real enough to teach you something.
This is the starting point discussed in detail in the full lenght article part of a larger series.
