Do you have an idea that has to exist before you can find out whether it works?
From concept to a deployed first version that real users can be put in front of: web applications, panels, map-based products and mobile apps, kept small enough to learn from.
The problem
The idea is usually clear. What is unclear is which parts of it matter. Teams either build everything at once and launch late with a product nobody has touched, or they build a prototype so thin that the feedback is about the prototype rather than the idea. Both waste the one resource that matters at this stage, which is a fast, honest answer.
How we approach it
We define the one question the first version must answer, then build only what is needed to answer it, and build it properly: real accounts, real data, deployed on infrastructure that will not embarrass you if the answer is yes. Everything else is cut or faked openly. We instrument the product so the answer comes from usage rather than opinions, and we plan the second version only after the first one has been used. We have shipped products this way as the sole developer, from the first commit to a released 1.0, and we have also retired one at that point because the answer was no. That is a cheap outcome compared with a year of building.
Worked example
A geographic information system, panel and maps included
Four years of building geographic information products taught us where such projects stall: the map is the visible part, but the product lives in the panel behind it. On a current web GIS we built that entire management panel on our own, from user and role administration to the workflows that feed the map, and implemented the map operations that let people draw, query and edit features on it. A mobile product went the other way: three partners, one developer, and a version 1.0 released to real users. It was retired shortly after, on the strength of what those users did, which is exactly what a first version is for.
What you get
- A written scope for the first version, with what was cut and why
- A deployed product with real accounts, real data, and usage instrumentation
- A short usage report after the first weeks, in plain language
- The codebase and infrastructure, documented and yours to continue with