Your developer recommends MongoDB over PostgreSQL, microservices instead of a monolith, and a custom API layer. You nod along, hoping they know what they’re doing. Without technical fluency, you’re trusting decisions that could cost you months and thousands of dollars to reverse later. The right questions don’t require you to learn programming, just to understand whether your developer is solving real problems or building their portfolio project on your budget.
Why can’t we use a managed platform instead?
This question forces your developer to justify custom development against the simpler alternative. A good developer explains specific technical requirements that platforms can’t meet: unique performance needs, regulatory constraints, or integration requirements that demand custom architecture.
A bad developer responds with vague concerns about “limitations” or “not being enterprise-ready” without concrete examples. They might claim platforms can’t scale, which is false for modern services like Supabase that power apps with millions of users. They might argue custom gives you more control, which is true but rarely worth the cost for early-stage products.
Listen for specifics. If they say “we need custom because your app requires real-time collaboration,” that’s a red flag because platforms like Supabase include real-time features built-in. If they say “we need custom because you’re processing satellite imagery with algorithms that don’t exist in any platform,” that’s legitimate justification.
The best developers start with platforms and only recommend custom development for components that genuinely require it. Learning how Supabase becomes your startup’s toolbox means understanding when the toolbox is sufficient versus when you need specialized tools built specifically for you.
How long will this take and what happens if we’re delayed?
Developers underestimate timelines systematically because they quote best-case scenarios. A four-month estimate assumes perfect requirements, no unexpected challenges, and no scope changes. Reality adds delays, so you need to understand the padding and what triggers extensions.
Ask what assumptions the timeline is based on. If they say “four months assuming the third-party API we’re integrating works as documented,” you know that if the API has issues, the timeline extends. If they say “four months assuming requirements don’t change,” you know that any feature additions push the deadline.
Good developers build buffer into estimates and communicate uncertainty honestly. They might say “four months most likely, but could extend to five if we hit unexpected integration issues.” Bad developers promise aggressive timelines to win the project, then blame delays on factors outside their control.
Ask what happens if the timeline doubles. If four months becomes eight months, can you afford the additional cost? Will the developer stay committed or will they take other projects and split their attention? Understanding build vs. buy and why hiring a developer to build a custom backend is usually a mistake includes recognizing that timeline risk is often the deciding factor against custom development.
What happens when you’re not available?
This question reveals single-person dependency risk. If your developer is the only one who understands the backend, you’re vulnerable every time they’re sick, on vacation, or pursuing other opportunities. The answer should include documentation, code clarity, and transition plans.
Good developers write documentation that explains architectural decisions, setup processes, and common maintenance tasks. They structure code clearly with comments and standard patterns that other developers can understand. They’re willing to do knowledge transfer sessions if they eventually hand off the project.
Bad developers build opaque systems that only they understand, either unintentionally through poor practices or intentionally to create dependency. They might say “the code is self-documenting” which usually means it’s not documented at all. They might resist documentation because it takes time they’d rather spend coding.
Ask specifically how another developer would take over if necessary. Would it take them days or weeks to understand the codebase? Is there architectural documentation explaining how components connect? Are there setup scripts that automate deployment, or does it require tribal knowledge that only exists in your developer’s head?
Managed platforms eliminate this dependency. Business autopilot through edge functions that automate tasks means those functions are deployed on infrastructure that anyone can access and modify. The platform’s documentation explains how things work, and any developer familiar with the platform can maintain your code without specialized knowledge.
How will we handle security and who’s responsible for patches?
Security isn’t a one-time implementation, it’s ongoing maintenance. Libraries get vulnerabilities, frameworks need updates, and server software requires patches. Someone needs to monitor security advisories, apply updates, and test that nothing breaks.
Ask whether the developer includes security maintenance in their quote or if it’s an additional ongoing cost. Ask how quickly they’ll respond to critical vulnerabilities that need immediate patching. Ask what happens if a vulnerability is announced six months after they’ve finished the project and moved on.
Good developers plan for security maintenance as part of the engagement. They might offer a maintenance retainer at hourly rates, or they might recommend monitoring services that alert you to vulnerabilities. They acknowledge that security is continuous and have a clear process for handling it.
Bad developers treat security as someone else’s problem after delivery. They build the system, hand it over, and expect you to handle maintenance without providing documentation or processes for doing so safely. This leaves you vulnerable to attacks because you don’t know what needs monitoring.
Protecting your assets by controlling who sees what in your database extends beyond application code to infrastructure security. Managed platforms handle security patching automatically, applying updates without requiring your intervention or technical knowledge. Custom infrastructure puts that responsibility on you or your developer.
What’s our monthly cost after launch and how does it scale?
Initial development cost is only part of the equation. Hosting, databases, monitoring, backups, and third-party services create ongoing monthly expenses that scale with usage. You need specific numbers, not vague estimates.
Ask for a breakdown at different user levels: 100 users, 1,000 users, 10,000 users. Ask what happens if you get sudden traffic spikes. Ask which costs are fixed and which are variable. Ask if there are minimum commitments or if you can scale down during slow periods.
Good developers provide detailed cost projections including hosting, database, CDN, monitoring, backups, and all third-party services. They explain which providers they’re recommending and why, and they’ve researched pricing tiers to give you accurate estimates.
Bad developers wave away cost questions with “it depends on usage” without providing scenarios. They might underestimate hosting costs because they haven’t actually deployed similar applications before. They might ignore costs like monitoring or backups that seem optional but become critical in production.
Avoiding “bill shock” by predicting your monthly tech costs requires understanding these projections before development starts, not discovering them when the first invoice arrives. If monthly costs will exceed your budget at the scale you’re targeting, that’s critical information for deciding whether to proceed with custom development.
Can we export our data and move to another platform if needed?
Lock-in is dangerous for startups. If costs become unsustainable or the developer relationship sours, you need the ability to move your data to a different platform without starting from scratch. The answer reveals whether you’re building on open standards or proprietary architecture.
Good developers use standard databases like PostgreSQL, standard file formats, and well-documented APIs that make migration possible. They can explain exactly how you’d export your data and what would be required to move to a different hosting provider or platform.
Bad developers build proprietary systems that make migration extremely difficult. They might use obscure databases, custom file formats, or tightly coupled architecture where extracting your data requires significant development work. This creates dependency that limits your options.
Ask specifically: “If we need to move our database to a different provider, how would we do that?” Ask: “Are we using standard formats for data storage or custom formats?” Ask: “Could another developer take our data and deploy it on different infrastructure if necessary?”
Knowing why being open source means you’ll never be locked in applies beyond platforms to custom development. Open source databases, frameworks, and tools give you migration paths. Proprietary systems trap you with the original developer and their technical choices.
How will we know if something breaks in production?
Applications fail in production. Servers go down, databases hit capacity limits, external APIs stop responding, and bugs that passed testing manifest under real-world usage. You need monitoring and alerting so you know about problems before users complain.
Ask what monitoring tools they’re implementing. Ask how you’ll be notified when errors occur. Ask what metrics they’ll track and how you’ll access them. Ask whether monitoring is included in the development cost or if it’s an additional expense.
Good developers include monitoring as a standard part of deployment. They set up error tracking, performance monitoring, and uptime checks. They configure alerts that notify relevant people when thresholds are exceeded or services go down. They give you dashboard access so you can see system health yourself.
Bad developers skip monitoring to save time or cost, leaving you blind to production issues. The first you hear about problems is when users report that features aren’t working. By then, the issue might have affected dozens of users and damaged your reputation.
Managed platforms include monitoring built-in. Supabase provides dashboards showing query performance, error rates, and resource usage. Understanding how to keep your monthly software bill under $50 includes leveraging platform monitoring instead of paying for separate monitoring services that custom infrastructure requires.
What’s your testing process and how do we avoid bugs?
Testing prevents bugs from reaching production, but not all developers prioritize it. Some write comprehensive automated tests that catch issues before deployment. Others test manually and hope for the best. You need to know which approach your developer takes.
Ask what percentage of code will have automated tests. Ask whether they’ll test on staging environments before production deployment. Ask how they’ll handle bug reports after launch and whether fixes are included in the original quote or charged separately.
Good developers write automated tests for critical functionality, use staging environments to verify changes before production, and include a reasonable bug-fix period in their engagement. They might guarantee 30 or 60 days of bug fixes after launch, acknowledging that some issues only appear with real usage.
Bad developers skip testing to ship faster, then spend months fixing bugs that should have been caught before deployment. They might charge hourly rates for bug fixes, turning quality issues into additional revenue rather than treating them as part of delivering working software.
Ask specifically: “What happens if we find bugs in the first month after launch?” The answer reveals their commitment to quality and whether they stand behind their work or nickel-and-dime you for every issue.
Why are you choosing this database over alternatives?
Database choice affects performance, costs, scalability, and your ability to migrate later. PostgreSQL, MySQL, MongoDB, and other databases have different strengths, and the choice should be based on your specific needs, not developer preference.
Good developers explain the trade-offs. They might say “PostgreSQL because you need complex relational queries and strong consistency guarantees” or “MongoDB because you’re storing unstructured data that doesn’t fit relational schemas.” The explanation should connect database features to your product requirements.
Bad developers choose databases based on personal preference, resume building, or what’s trendy. They might pick MongoDB because it’s “web scale” without explaining why you need that. They might choose a database they’re familiar with even if it’s not optimal for your use case.
Ask: “What would be different if we used PostgreSQL instead of MongoDB?” or vice versa. If they can’t articulate meaningful differences or explain why one is better for your specific needs, that’s a red flag. Database choice is a fundamental architectural decision that affects everything built on top of it.
Learning how Supabase becomes your startup’s toolbox includes understanding that PostgreSQL is the foundation. It’s a proven, scalable, open-source database that’s been production-tested by the largest companies in tech. Developers who recommend exotic databases for simple CRUD applications might be over-engineering.
How much will it cost to change requirements midway?
Requirements always change. You’ll discover features you need, features you don’t need, and features that need to work differently than originally specified. Understanding the cost of changes helps you budget and prioritize.
Good developers build flexibility into their architecture and pricing. They might include a small number of change requests in the base price, or they might clearly state hourly rates for changes beyond the original scope. They structure the project in phases so you can adjust direction between phases.
Bad developers treat any change as a major disruption requiring full repricing. They might resist changes entirely, insisting you stick to original specifications even when market feedback suggests adjustments. Rigidity costs you agility, which is often more valuable than getting the original plan perfect.
Ask: “If we realize midway through that we need to add two-factor authentication, what would that cost and how would it affect the timeline?” Specific scenarios get specific answers that reveal their flexibility and reasonableness.
Understanding the “free tier” trap and what tech companies don’t tell you about growth parallels understanding change order costs. Both require knowing the real costs before you’re committed, not discovering expensive surprises after you’ve invested time and money.
What documentation will we receive and can someone else take over?
Documentation is how knowledge transfers from the developer to you and future maintainers. Without it, you’re dependent on the original developer to explain how things work, make changes, or fix problems. Good documentation makes the system understandable to others.
Ask specifically what documentation you’ll receive: architectural diagrams, API documentation, deployment instructions, database schema explanations, and code comments. Ask whether documentation is included in the base quote or if it’s an additional cost.
Good developers document architecture, setup processes, and common maintenance tasks as part of professional practice. They create README files explaining how to run the project locally, deploy to production, and troubleshoot common issues. This documentation makes the codebase accessible to other developers.
Bad developers consider documentation optional or charge extra for it. They might say “the code documents itself” or “I’ll explain it to you when we’re done.” This creates dependency and makes the system opaque to anyone who wasn’t involved in development.
Documentation quality reveals professionalism. Developers who document well tend to write cleaner code, think about long-term maintenance, and build systems that others can work with. Developers who skip documentation often create technical debt that becomes your problem.
These questions help you evaluate technical decisions, but security and cost management are ongoing concerns that require deeper understanding. The entrepreneur’s guide to app security and data safety brings together security practices, cost optimization, and compliance into a comprehensive framework for running your business with confidence instead of constant worry.
About the Author
