The short answer
The seven questions that separate a good custom software developer from a costly mistake: who owns the code, what is the maintenance model, how do you handle integrations, what is in the contract, what happens if we disagree, who handles hosting, and what is my escape hatch. None of them takes technical knowledge to ask. A good developer answers each one plainly and in writing; a vague answer shows you where the risk sits.
Each section below covers why the question matters, what a good answer sounds like, the red flags, and a common way it goes wrong. Bring the list to your discovery call.
1. Who owns the code?
Everything else on this list rests on this one. If the code, the domain, or the accounts the software runs on sit with the developer, changing developers or fixing anything without them gets hard. Don't assume paying for the build settles it; get the answer in writing.
A good answer: you own the code, the domain, and the data, and the contract says so. The code lives in a repository your business controls — on GitHub, for example, an organization you own, with the developer added as an outside collaborator whose access you can remove.
Red flags:
- The contract grants a license to use the software, not ownership of it.
- The code sits only in the developer's accounts until the project ends.
- “Don't worry, it's all yours,” with nothing in writing.
How it goes wrong: a common pattern is a business that pays for a customer portal while the code stays in the developer's account. Years later the relationship ends over something unrelated. The portal still runs, but nobody else can change it, and every replacement quote starts from scratch.
2. What is the maintenance model?
Software isn't finished at launch. Browsers update, security patches land, connected services change their APIs, and your needs change. Agree who does that work, how fast, and at what price before launch, not the week something breaks. For planning, budget 15–20% of the build cost per year; our maintenance cost guide breaks that down.
A good answer: a written plan for life after launch — how long included support lasts, what maintenance costs afterward, how quickly someone responds, and whether that someone knows the system.
Red flags:
- “It won't really need maintenance.”
- Support with no stated response time or price.
- Software that stops working if you cancel the maintenance plan.
How it goes wrong: take a five-person firm whose scheduling tool runs fine for eighteen months with no maintenance agreement. Then a browser update breaks the booking form, the original developer has moved on, and bookings go back to paper while the firm hunts for someone willing to learn the code.
3. How do you handle integrations?
Every connection to a payment processor, accounting system, or CRM is its own small project, and integrations are where budgets quietly grow: a reasonable 2026 estimate is $2,000–$5,000 per integration. Our guide to connecting QuickBooks, Stripe, and your CRM covers the common ones.
A good answer: they ask what systems you use before quoting, name each integration in the written scope, and explain what happens when the other side misbehaves. That isn't hypothetical: Stripe's documentation on event notifications warns that the receiving software “might occasionally receive the same event more than once,” and that Stripe doesn't guarantee events arrive in order. Solid integrations plan for that, with testing, retries, and monitoring that flags a stalled sync.
Red flags:
- “It has an API, so it'll be easy,” said before anyone has read the documentation.
- No plan for the day a vendor changes its API.
How it goes wrong: a common pattern is a nightly sync to the accounting system that quietly stops after the vendor changes something. Nothing alerts anyone, and weeks later someone is re-entering invoices by hand.
4. What is in the contract?
The contract turns every other answer on this list from something said on a call into a commitment.
A good answer: a contract, or a signed scope document it references, covering at least:
- Scope: the screens, workflows, data, and integrations, specific enough to settle an argument.
- Price and payments: fixed or hourly, with payments tied to milestones you can see working.
- Changes: how new requests get priced and approved.
- Ownership: the code, domain, data, and accounts.
- After launch: included support, and what it costs afterward.
- Ending early: what you receive if the engagement stops.
Have your attorney review it before signing; this is a checklist for that conversation, not legal advice.
Red flags:
- A one-page quote with a price and no scope.
- A fixed price with no discovery behind it, which our cost guide explains means either an under-defined scope or a hidden contingency.
How it goes wrong: a common pattern is a quote that says “customer portal,” a price, and little else. Halfway through, the client expects document uploads; the developer says they were never included. Both are honest, and neither can prove it.
5. What happens if we disagree?
Disagreements happen: whether something was in scope, whether a problem is a bug or a new feature, whether the work is done. The damage comes from having no agreed way to settle them.
A good answer: a process, not reassurance. The signed scope is the reference. Anything outside it becomes a change order with a price and a timeline impact, and you decide whether to do it. Regular demos help too: a misunderstanding caught in a weekly demo is a conversation; found at launch, it's rework.
Red flags:
- “That never happens with us.”
- Changes agreed verbally, with the cost appearing later on an invoice.
How it goes wrong: picture a client who first sees the software a week before launch. It matches the kickoff meeting, not how the office works. The developer calls the fixes new scope, the client calls them bugs, and the software sits unused while both sides wait each other out.
6. Who handles hosting?
Whoever controls the hosting account controls whether your software stays up. It's also a recurring cost, typically $20–$200 per month for most small-business apps.
A good answer: the hosting account is in your business's name and billed to you, and the developer works in it under a login you can revoke. On AWS, for example, the account's root user has complete access to all services and resources in the account, and AWS strongly recommends against using it for everyday tasks — so keep that login yourself. The domain gets the same treatment. Hosting through the developer can work too, as long as you can get a full copy on request.
Red flags:
- Hosting or the domain in the developer's name “to keep things simple.”
- Backups nobody has ever tested by restoring one.
How it goes wrong: a common pattern is a developer who runs a client's app on their own account and credit card. Years later the card expires, the app goes offline, and the client discovers they never had a login to any of it.
7. What is my escape hatch?
Developers retire, get busy, or stop being the right fit. That's survivable if someone else can pick the system up, and the time to check is before you need it.
A good answer: things you can verify at any point during the project.
- The code in a repository you control, with its full history.
- Admin access to the hosting, the domain, and every third-party service.
- A way to export all your data in a standard format.
- Documentation a new developer could follow to run and deploy it.
If the code sits in the developer's GitHub account, they can move it to yours: GitHub's documentation notes that a transferred repository keeps its commit history, issues, and pull requests.
Red flags:
- A proprietary framework only this developer can work with.
- A handover fee that appears only when you ask to leave.
How it goes wrong: a common pattern is a solo developer who supports a business's order system well for years, then takes a full-time job and stops answering email. Nothing is written down, and the next developer's first weeks go to working out how it runs. For more warning signs, see why custom software projects fail.
How Pythn answers the seven
It's only fair to answer them ourselves.
- Code ownership: yours — the code, the domain, and the data, from day one.
- Maintenance: 30 days of post-launch support included, then a maintenance retainer or on-demand work, your choice, with direct access to the developers who built it.
- Integrations: specified in the written design document; integration engagements include error handling, retry logic, and observability so you know when something breaks.
- Contract: a fixed scope and a fixed price in a design document you sign off on before building begins.
- Disagreements: weekly demo calls surface problems early, and changes are re-scoped openly, not snuck onto invoices.
- Hosting: Pythn can host it, deploy it to your own cloud account, or hand you the keys; either way, you own the deployment.
- Escape hatch: host it anywhere, hire anyone to maintain it, or bring it back to us. Every backend ships with API docs, integration tests, and a deployment runbook.
The process page walks through all five stages, about Pythn covers how we operate, and the services overview shows what we build.
Frequently asked questions
Who owns the code when I hire a developer?
It should be you, but don't assume it — get it in writing. The contract should name the code, the repository, the domain, the data, and the hosting accounts as yours, and your attorney should review that clause. If it describes a license to use the software rather than ownership, ask why. At Pythn Development, clients own the code, the domain, and the data from day one.
What should be in a custom software contract?
At minimum: a written scope covering screens, workflows, data, and integrations; the price and payment schedule; how changes are priced; who owns the code, domain, and data; what support is included after launch; and what you receive if the engagement ends early. Have an attorney review it before signing. At Pythn, scope and price are fixed in a design document you sign off on before building begins.
How much should I budget for maintenance after launch?
A reasonable planning figure is 15–20% of the build cost per year, plus hosting at $20–$200 per month for most small-business apps. On a $20,000 build, 15–20% is $3,000–$4,000 a year. Our maintenance cost guide breaks it down.
Which red flags should rule a developer out?
Vagueness about anything that matters after launch. A developer who's specific about features but vague about ownership, support, hosting, or leaving is showing you where the risk sits. Also watch for a fixed price with no discovery behind it and changes that never get written down. More in why custom software projects fail.
Do I need to be technical to ask these questions?
No. None of the seven takes technical knowledge, and a good developer can answer every one in plain English. If an answer only makes sense to another developer, ask again — how they handle that is an answer in itself. Our discovery call guide covers how to prepare for that first conversation.