Non-technical founder? Ask your developer these 6 questions
Use six concrete questions to understand delivery, ownership, running costs and what happens when something goes wrong.
On this page
Outcome and demonstrationOwnership and accessCost and changeRecovery and acceptanceKey takeawaysYou do not need to learn a programming language to assess a development proposal. You need clear answers about the outcome, the evidence and the responsibilities. A good partner should be able to explain those things without asking you to take the technical detail on trust.
1. What will a user be able to finish? 2. When can I try it?
Ask for a plain description of the first complete journey. “A dashboard and an API” names components. “A customer can choose a slot, book it and receive a confirmed meeting link” describes a result you can review. Agree the important failure cases too, such as a slot being taken before confirmation.
Then ask when you will see a working version. A short feedback cycle makes misunderstandings easier to correct. A demonstration should use the actual product where possible, with clear labels for simulated integrations. Attractive screens alone do not prove that data is saved, permissions work or emails are sent.
3. What will the business own and control?
Clarify ownership of source code, domains, hosting accounts, design assets and operational documentation. Ask how another competent team could build and run the application if the relationship changes. Check whether third-party licences or subscriptions affect that handover.
Staff should use individual accounts with appropriate permissions. Shared passwords make accountability and access removal harder. Decide who controls recovery and billing, and how access is withdrawn when a contractor leaves. These are ordinary operating questions, not signs of distrust.
4. What are the ongoing costs? 5. What happens to a new idea?
Separate the build fee from hosting, external APIs, maintenance and support. Ask for the assumptions behind usage estimates and what would make the bill grow. If a proposal depends on a free tier or promotional credit, ask what happens when it ends.
Agree how changes are handled during delivery. A useful process explains the effect on scope, timing and cost before work begins. Keep a later-release list for ideas that do not serve the first outcome. This protects the launch date without losing good suggestions.
6. How will we know it works, and how will we recover?
Ask for acceptance checks written as things you can observe. These might cover mobile use, a real booking, an administrator's permissions and what the user sees when an integration fails. Agree who reviews the result and how unresolved defects are recorded.
Finally, ask about backups, monitoring and release rollback. A backup is useful only if the team knows how to restore it. A support promise needs an owner and a contact route. You are looking for clear responsibilities and evidence, not a guarantee that software can never fail.
Key takeaways
- Review complete user journeys rather than component lists.
- Keep ownership, access and costs explicit.
- Agree acceptance and recovery before launch.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.