What you actually need to know
Non-technical founders hire developers and get lost. They cannot evaluate quality, they cannot tell when estimates are padded, and they cannot detect when the architecture will cause problems in six months.
This guide is not about learning to code. It is about learning enough to have informed conversations, make smart hiring decisions, and protect yourself from the most common mistakes.
The vocabulary that matters
You do not need to understand every technical concept. You need to understand the ones that show up in every project decision.
Frontend vs backend. Frontend is everything the user sees — the interface, the design, the buttons. Backend is everything that happens behind it — data storage, business logic, integrations. Most projects need both. Some (static marketing sites) need only frontend. Some (data pipelines) need only backend.
Database. Where your data lives. The two main types are relational (PostgreSQL, MySQL — tables, rows, columns) and document-based (MongoDB — flexible JSON-like structures). Most business applications use relational. The choice matters more than it sounds.
API. Application Programming Interface. How systems talk to each other. When Stripe charges a credit card, that is an API call. When your app sends a Slack notification, that is an API call. APIs are the plumbing between software components.
Deployment. Making the software live. This involves servers, cloud providers (AWS, GCP, Vercel), and configuration. A dev environment is where code is written. Staging is where it is tested. Production is where real users are.
Technical debt. Work that was done quickly rather than correctly, creating future problems. Every shortcut is a loan against future development speed. All projects accumulate some. The question is how much and whether it is managed.
The red flags that signal a bad engagement
"We'll figure out the requirements as we go"
No. Requirements change, but the core scope must be defined before coding starts. Any developer who resists this is protecting their ability to bill for scope creep.
Hourly billing with no estimate
Some hourly work is legitimate. All-hourly with no ceiling is not. Always negotiate a not-to-exceed on hourly projects or push for milestones.
No staging environment
If the developer is deploying directly to production, they have no safe place to test. This means your users are the QA process.
"That's technically impossible"
Almost nothing is technically impossible. "That's technically impossible" usually means "I don't know how to do that" or "I didn't build the system to support that." Ask for clarification.
Refusing to explain decisions
You don't need to understand the code. But you should be able to ask "why did you choose PostgreSQL over MongoDB for this?" and get a clear, non-condescending answer.
No documentation, no comments, no README
The developer knows the code today. You need the code to be understandable when they are gone.
How to evaluate a build without reading code
You cannot review code quality without technical knowledge. But you can evaluate signals that correlate with quality:
Does the project have a README? A good README explains how to run the project locally, what the architecture is, and what environment variables are needed. No README is a strong signal of poor craftsmanship.
Can you log in to staging and test features before they go to production? If there is no staging environment, quality is going directly to production untested.
Are there tests? Ask. You can see the test files in the repository. A project with no tests is high-risk — any change could break anything else.
Are there more than two people who understand the codebase? Single points of failure in a development team are a business risk. If one person leaving would stop your project, that is a problem to solve now.
Does the developer explain trade-offs, or just present decisions? Good developers acknowledge trade-offs: "we went with option A because of X, but it means we'll need to revisit Y later." Presenting everything as the obvious right answer is a sign of inexperience or salesmanship.
How to write requirements that developers can actually use
Developers build what is specified, not what is implied. Vague requirements produce software that does not match your mental model.
Good requirements are:
- Specific: "A user can submit a contact form with name, email, and message. The form validates that all three fields are filled before submitting."
- Testable: You can definitively say whether it works or not.
- Prioritized: Some things are must-have, some are nice-to-have. Mark them.
Bad requirements are:
- "A contact form" (what fields? what happens after submission? where does the data go?)
- "It should feel fast" (define fast — specific load time targets)
- "User-friendly" (what does that mean for your specific users?)
The single most valuable thing you can do before starting a project is write requirements at this level of specificity. It takes a day. It saves weeks.
The right questions for your first developer meeting
- What are the core entities in this system? (This tells you if they understand the data model)
- What will be hardest about this project, technically? (Good developers know where the complexity is)
- What happens when X fails? (Where X is a key integration — payment processor, email provider, etc.)
- How will I be able to test new features before they go live?
- What does handoff look like? What will I need if I bring in a different developer?
You do not need to understand the answers in depth. You need to observe whether the developer thinks in these terms. Developers who do not think about failure modes, testing, and handoff are not production-ready.