When I review an idea for a software product, I start with the decision it needs to support. A budget can disappear into untested assumptions and features that do not help resolve them. Before estimating, I write down the user, problem, critical journey and evidence needed to fund the next step.
If the problem or buyer is still unproven, start with validating the idea before coding. This guide covers the next decision: which software is needed to test actual use.
Start with the decision the MVP must unlock
Write one measurable question: will a specific customer complete a specific workflow and accept a specific commercial condition? Interviews, a prototype or a manual concierge service may answer it before software is necessary. Code only the uncertainty that cannot be tested more cheaply.
Define success and stop conditions in advance. Useful metrics include activation, successful task completion, repeated use, qualified requests or paid conversions. Page views alone rarely validate a product.
Turn scope into one vertical slice
A credible MVP normally needs one complete path: sign in, provide the minimum input, receive the promised result and recover from an error. Keep administration manual when volume is low. Prefer established authentication, payments, email and hosting services to custom infrastructure.
Separate must work now, can be manual and later. Each feature needs an owner, acceptance criterion and reason tied to the experiment. This is the same discipline described in how I think about a technical project before writing code.
Scope example: a B2B request portal
This is a hypothetical example, not a client project. A business wants to learn whether customers can submit complete requests and check progress without chasing the team by email. The first version would test that journey with invited users. Participant count, observation period and thresholds should be agreed before the pilot, based on how often the process actually occurs.
| Need | First version | Explicit boundary |
|---|---|---|
| Submit a request | Required inputs, confirmation and a request identifier. | One request type; no form builder. |
| Check progress | Customers see their requests and the latest confirmed status. | No access to other companies' data; no custom reporting. |
| Handle requests | An operator reviews requests and updates status manually. | Record ownership and time spent; defer ERP synchronisation. |
| Invite customers | Invitation-based access with verifiable permissions. | No public registration, subscription plans or automated billing. |
| Measure the experiment | Journey starts, valid submissions, status checks and operator assistance. | Count unique requests; exclude team tests. |
These exclusions only work if they preserve the hypothesis. If value depends on an instant ERP price, I would test that integration or change the experiment instead of quietly substituting manual work. Every manual step needs an owner, a capacity limit and a record of effort.
Accepting delivery and validating the business are separate decisions
To accept delivery of this example, I would ask for a reproducible demonstration of these checks:
- An invited customer submits a valid request and can find it again.
- Incomplete inputs produce a clear error and can be corrected.
- Resubmitting after a connection failure does not create another request for the same operation.
- A customer cannot read or change another company's requests, including by changing a URL.
- An operator updates a status with a record of who changed it and when.
- A backup is restored in a test environment and service recovery is documented.
Passing these checks establishes what was delivered. To decide whether the business warrants more investment, I would observe how many invited users complete the task, how much help they need and whether they return when another need occurs. Repeat use cannot be assessed if the observation window ends before the next usage cycle. Free portal use does not validate a payment hypothesis.
Before the pilot, I would record each signal's source, denominator, agreed threshold and decision owner. Continue when evidence is sufficient and operations are manageable; revise the journey when manual assistance makes the result hard to interpret; stop or revisit the hypothesis if the need does not materialise. Too few participants or too little time makes the result inconclusive. Moving the threshold afterwards does not turn it into success.
A lean technical plan
- map the critical user journey and failure states
- prototype uncertain screens before backend work
- choose a conventional stack the team can operate
- define the smallest data model and API contract
- integrate managed services for commodity capabilities
- release behind basic monitoring and backups
- measure behaviour, interview users and revise scope
A modular monolith is often enough. Add queues only for slow or retryable jobs, and avoid microservices until independent scaling or ownership is real. Security, privacy, access control and data deletion are not optional, even in an experiment.
The Adslyfy case study shows runs, failures and screenshots in an ad-monitoring platform. That evidence illustrates operational visibility; it does not establish demand or outcomes for the hypothetical portal.
Control budget through checkpoints
With scope written down, use the software quote comparison guide. Ask the proposal to separate discovery, implementation and pilot operations, with unresolved dependencies identified. There is no universal price that can replace those decisions.
Fund discovery, prototype, vertical slice and pilot as separate checkpoints. At each checkpoint, compare evidence against the success criteria before authorising more work. Track remaining scope, delivery risk and monthly operating cost—not only hours already spent.
Use production-like deployment early enough to expose DNS, email, permissions, mobile behaviour and third-party limits. Keep logs and analytics proportionate, avoid unnecessary personal data, and document important decisions so a later team can understand why shortcuts exist.
Before expanding the pilot, compare the total cost of operating and maintaining the software: manual review, external services, updates and exit. Lower development spending can shift work to your team; measure it before funding the next phase.
Common mistakes
- building for every possible customer
- copying a mature competitor feature by feature
- starting with microservices or native apps without evidence
- hiding manual operational work from the cost model
- accepting vague estimates without assumptions
- changing scope while keeping the same deadline and budget
- launching without analytics, error reporting or backups
- treating compliance and security as post-MVP tasks
Practical MVP checklist
- one named target user and painful problem
- one critical workflow and measurable outcome
- written exclusions and stop conditions
- prototype tested with representative users
- conventional, maintainable stack
- basic authentication, permissions and data protection
- error tracking, audit events and restore-tested backups
- operating-cost estimate at pilot volume
- weekly scope and risk review
- clear decision after the pilot
When hiring a technical person makes sense
A technical lead becomes valuable before development when integrations, sensitive data, automation, legacy systems or regulatory constraints can change the architecture. They can challenge estimates, define the vertical slice and distinguish reversible shortcuts from expensive traps. For a broader view, see what a small business can automate on a small budget.
Define the MVP before commissioning development
If you are preparing a first version, I can help turn the idea into scope that can be built and checked. Explore my custom software and SaaS development service or tell me about the problem, including the target user, current process, available evidence and constraints. The next step is deciding what belongs in the pilot.