Decide what the first version needs to prove
A proof of concept, a demo and a minimum viable product (MVP) serve different purposes. Agree which you need before discussing the build.
| First version | Its purpose | What to check |
|---|---|---|
| Proof of concept | Can this technical idea work? | A focused experiment with a clear result. |
| Demo | Can people understand and respond to the idea? | A reliable demonstration, with any simulated parts understood. |
| MVP | Can a small, real product help a specific group of users? | Useful functionality with the security, support and reliability those users need. |
One piece of work can serve more than one purpose. My HR voice-assistant demo helped a client show the idea to potential clients and investors while demonstrating technical feasibility.
There is no fixed build time for an MVP. Keep the first release focused on a useful outcome for a defined audience, and estimate the work needed to deliver it.
Choose how to get it built
First check whether an existing product meets the need. Building gives you more control, but it also gives you responsibility for operating and maintaining the software.
| Approach | What it offers | What to allow for |
|---|---|---|
| Buy a product | A service you can evaluate before committing to a build. | Fit, ongoing fees, data export and supplier dependence. |
| Build in-house | Product knowledge and ongoing development within your team. | Hiring, design, testing, technical leadership and continuity. |
| Outsource | Access to delivery skills for an agreed piece of work. | Clear scope, regular demonstrations, account control and handover. |
| No-code or low-code | Tools for assembling workflows and testing ideas. | Platform limits, running costs and how you could move away. |
A single developer can move quickly, but concentrates knowledge in one person. Whether you hire an individual or a team, establish how work will be reviewed and how someone else could take over.
AI-assisted coding can help produce software quickly. The result still needs someone who can review the code, test its behaviour and take responsibility for security and maintenance.
Start with the problem people have
Find out how potential users handle the problem today, what gets in their way and whether your idea would change what they do. A few conversations and rough screens can expose assumptions before you invest in a full build.
- Write down the task you want to help with and the assumptions behind your idea.
- Speak to people who match your intended users. Ask about actual experiences and workarounds.
- Show a sketch or a simple screen. Ask what they think it does and what they would try first.
- Record confusion and disagreement, then decide what needs changing or further investigation.
Early feedback helps you decide what to investigate next; it does not prove demand on its own. A researcher or UX designer can help you recruit suitable participants and avoid leading questions.
If a technical uncertainty could change the decision to build, test it with a focused proof of concept. Otherwise, use what you learn to define the smallest useful scope.
Connect the plan to working software
A roadmap describes the outcomes and priorities. A backlog contains the work needed to achieve them. Keep the connection visible, so a list of completed tasks tells you something about progress.
- User needWhat someone needs to accomplish.
- Planned workThe features and supporting tasks.
- DemonstrationWhat the team can now show working.
- FeedbackWhat to improve or prioritise next.
Include all the people using the system: customers, staff and administrators may need different permissions and workflows. Plan supporting work such as login, uploads, email, security, monitoring and recovery where the product needs them.
Estimate in ranges and record assumptions, dependencies and unknowns. Include testing, deployment and feedback. A document or spreadsheet can work initially; use shared tickets when tasks and ownership need more active tracking.
Budget beyond the first build
The cost includes design, testing, deployment and ongoing care as well as code. Ask for those parts explicitly when reviewing a proposal.
Build
Research, design, development, testing and the first release.
Run
Hosting, email, external services, monitoring and support.
Maintain
Updates, fixes, security work and changes as the product learns and grows.
Estimate with the people doing the work. Separate understood tasks from investigation, make dependencies visible and translate the estimates into a cost range. State assumptions and exclusions so you can revisit the budget as you learn.
Fixed price
Useful when the scope is well defined. Agree acceptance criteria, quality expectations and how changes will be priced.
Time and materials
You pay for time as priorities evolve. Review progress, spend and remaining work regularly.
Adding people does not automatically shorten delivery in proportion. Some tasks depend on earlier work, and onboarding takes time. Identify the bottleneck before increasing the team.
Agree regular demonstrations, including explanations of infrastructure work with no visible screen. Repeated delays without a clear reason need attention.
Understand what will be hard to change
Make the decisions needed for the next useful step. For choices that can wait, record the uncertainty and when you need to resolve it. Keeping every option open can add complexity of its own.
Data structure and ownership deserve early attention. A schema describes how data is organised; a migration changes it while preserving existing information. Changes become more involved once real users and integrations depend on that structure.
For integrations, check the provider’s support, pricing, API stability and test environment. A sandbox lets the team test with isolated or simulated data. Plan how the product would respond if that service changed or became unavailable.
Hosting, deployment, security and privacy choices also affect cost and risk. You need a clear explanation of the trade-offs being accepted.
Make sense of the technical choices
Ask the team to explain how the proposed technology fits the product, who can maintain it and what would become difficult as usage grows. Familiar tools can be a sensible choice when they meet the requirements.
Often called the front end
Often called the back end
Some applications also use background workers for queued or scheduled work, such as sending emails or generating reports. This is a simplified model; systems vary.
Frameworks provide structure, libraries and conventions. Database choices affect how information is stored, queried and changed. Architecture describes how the parts fit together.
- Fit: what requirements does this choice meet?
- Support: who will update and maintain it?
- Continuity: could another team take over?
- Growth: what would need to change as demand increases?
More detail: languages and how code runs
JavaScript is the usual language for browser interfaces. TypeScript is converted into JavaScript for execution. Browsers also support WebAssembly for suitable workloads. For a small team, consider who can maintain the interface and the backend, and where specialist skills are needed.
Python is another popular back‑end language. It is common in AI, machine learning, and data processing, and it is often a good choice when those areas matter.
Languages use different execution models, and the boundaries overlap:
- JavaScript engines may compile code while it runs. Common Python implementations compile source to bytecode executed by a runtime. The runtime and the workload affect performance.
- Go, C++ and Rust commonly compile to machine code ahead of time. This can suit performance-sensitive services and particular deployment requirements.
- Java and C# commonly compile to an intermediate form, with runtime compilation or other compilation options depending on deployment. Performance depends on the implementation and workload, not a fixed ranking of language categories.
There is no single correct choice. The best decision is the one that fits your product, your team, and your hiring reality.
More detail: choosing a database
Relational databases organise data in tables and can enforce relationships between records. Document databases store data as documents, often with nested structures. Both approaches involve decisions about validation, queries and consistency.
Ask the team to explain the fit for your data and access patterns, backup and recovery arrangements, operating costs and how a future migration would work. Moving later may be possible, but it still requires planning and testing.
Agree what “done” means
Use version control, keep enough documentation for someone else to understand the system and agree a release process with a way to recover from failed changes. Track work so you can see what is in progress, blocked and complete.
- It worksThe agreed behaviour can be demonstrated.
- It is reviewedAnother developer has checked the changes.
- It is testedRelevant functional and security checks pass.
- It is acceptedThe person requesting it confirms it meets the need.
Testing should include the people who will use the product. Check that it solves their problem and is usable in practice, as well as whether individual features work.
What source control records
Source control tracks changes to code. Git is commonly used, with repositories hosted on services such as GitHub, GitLab or Bitbucket. Changes are saved as commits, giving the team a history it can review.
That history records committed changes; it can be rewritten and is not a complete audit of everything that happened. Preserve access, use review controls and discuss formal audit requirements separately.
Automate repetitive work where it saves time. Keep the process proportionate to the product, while making releases and recovery predictable.
Notice when the project is drifting
A single setback does not tell the whole story. Repeated patterns without a clear explanation are a reason to pause and check the basics.
You don’t have control
No company access to the repository or hosting. Critical credentials and data depend on one person’s account.
You can’t see progress
No working demonstrations, no visible priorities, or “almost done” for weeks. Costs rise while scope remains unclear.
Releases feel like a gamble
Features ship without user testing. Bugs cannot be reproduced, and nobody can explain the backup or rollback plan.
Bring the discussion back to ownership, access, visible work and quality. Ask for a concrete explanation of what is blocked and what will change.