Keys to the Castle: The 8-Item Checklist Before You Pay a Developer Another Cent

Eight items separate a business that owns its software from one that is renting it back from a developer. Ask for all eight before you pay a final invoice or sign a maintenance contract. 1. Repository access, and proof the repository is actually yours. Ask for the GitHub (or GitLab, or Bitbucket) link and check the ownership settings yourself. A repo sitting under the developer's personal account, even with you listed as a collaborator, is not the same as a repo owned by your organisation. Transfer ownership before final payment, not after. 2. A systems diagram. This is a simple picture showing how the pieces of your app talk to each other: the frontend, the backend, the database, any background jobs, and any external services. Without it, a new developer has to reverse-engineer the architecture from scratch before they can safely change a single line. 3. The database model or schema. What tables exist, what fields they hold, how they relate to each other. If your data model lives only in one person's memory, every future feature request starts with archaeology instead of building. 4. A list of every third-party service used for authentication and payments. Which provider handles login, which handles billing, and under whose account each one is registered. These are the services most likely to lock you out entirely if access lapses. 5. Where each environment is deployed, and where the secrets live. Development, staging and production each need their own entry: which hosting provider, which project or account, and where the API keys and environment variables for that environment are actually stored. 6. Admin logins to the deployment platform, and proof they work. A login handed over once and never tested is not a real handover. Log in yourself, change the password, and confirm you can deploy a change before you consider this item done. 7. Wireframes and a product roadmap. Not just what was built, but what was planned. This tells a new developer, or a new hire, what the intended direction was and stops them accidentally undoing decisions that were made for a reason. 8. A written record of why key decisions were made, not just what the code does. Code tells you what happens. It rarely tells you why a particular database was chosen, why a feature was scoped a certain way, or why a shortcut was taken under a deadline. Losing that context is one of the most common causes of expensive rebuilds. Ask for these eight items in writing, before the project is considered finished. A developer who resists handing any of them over is telling you something important about how the rest of the relationship will go.

Maintenance only covers what is written in the contract, nothing more. This surprises founders who assume "we'll maintain it" means their developer will drop everything for an urgent fix. In practice, a maintenance agreement is a list of specific tasks at a specific price. If something falls outside that list, even something you consider obviously urgent, the developer is under no obligation to treat it as a priority. They run a business too, with their own workload and their own priorities. Picture this: your checkout page breaks on a Friday afternoon. You call your development team and say you need it fixed by tomorrow morning. If that scenario is not covered in the contract, you are not calling in a favour from a partner. You are asking for a new quote. The answer might be yes, but it might cost an extra thousand dollars, and it will very likely take however long they decide it takes. This is not a reason to avoid maintenance contracts. It is a reason to read them properly and to ask a blunt question before signing: what happens if something breaks that we didn't think to list here? A developer who has a clear, reasonable answer to that question is worth far more than one who waves it away. It is also worth remembering that a maintenance contract is closer to a long-term relationship than a single transaction. You are effectively committing to this person or team for as long as the software runs, which could be years. Choose accordingly, and make sure emergency response is spelled out, not assumed. Plan for the possibility that whoever built your app is not reachable in two years. 370,500 Australian businesses exited in 2024-25, an exit rate of 13.9% (ABS, Counts of Australian Businesses, June 2025), and 88.8% of Australian businesses have four or fewer people, with 63.6% having no employees at all. A one-person development shop is the median supplier in this market, not an unusual one. The maintenance risk is measurable too. Symbiotic Security scanned 1,072 live applications built on vibe-coding platforms and found at least one security flaw on 98%, with critical flaws on 16% (Symbiotic Security, June 2026). Whoever holds the logins is the only person who can fix that class of problem. If that is not you, the checklist above is not paperwork, it is the difference between fixing your app and rebuilding it.

Ask any developer or agency what technologies they build with, then check independently whether people in your city could actually use that stack if you ever needed to switch. That single question tells you more about your future negotiating position than almost anything else in a sales call. Here's why it matters. A developer working in a common, well-supported stack, such as standard web frameworks and mainstream databases, can be replaced. If they disappear, raise their prices unreasonably, or simply do bad work, you can hire someone else to pick up the codebase within days. A developer working in an obscure or fully proprietary technology cannot be replaced nearly as easily, and that is sometimes the point. One founder who lived through a bad build described the logic of it plainly: if you wanted to build a business around holding client code hostage, you would deliberately choose a technology that is hard to find talent for, or invent your own so that only you know how to use it. You don't need to become a technical expert to run this check. Take the stack name the developer gives you, search for local job listings or freelancer profiles using it, and see how many turn up. Plenty of results means you have options later. Almost none means you are betting your business on one relationship staying good forever. This is also a fair question to ask early, before any contract is signed. A developer who answers openly and points you toward mainstream, well-supported technology is signalling confidence that their work will hold up to scrutiny from someone else. A developer who is evasive about their stack, or who talks you into something unusual without a clear technical reason, deserves more questions before you commit.

Run this same checklist on us before you decide whether to work with 13Labs. We would rather you score us honestly than take our word for it. On repository access, every 13Labs build ships in a repository under your organisation's own GitHub account from day one, not ours. You have owned it since the first commit. On the systems diagram and database model, our discovery phase produces both as written deliverables before a line of production code is written, and you keep them regardless of whether you continue with us. On third-party services, we document every auth and payment provider we connect, with the accounts registered in your name. On environments and secrets, we set up development, staging and production under your own hosting accounts where practical, and hand over environment variables as part of the standard build, not as a special request. On admin logins, we test deployment access with you before we consider a project closed, not just once at the end. On wireframes and roadmap, these come out of discovery as documents you keep. On the decision record, we write down why we made key architecture and scope choices as we make them, not reconstructed afterwards from memory. On the stack question, we build on mainstream, well-supported technology, chosen deliberately so that any competent developer in Melbourne, or anywhere else, could pick up the codebase without needing us specifically. We are not claiming to be perfect on every point every time. We are saying the checklist is a fair test, and we would rather you apply it before you sign than discover a gap after you have paid.

Who legally owns code written by a developer I paid? In most cases, ownership depends entirely on your contract, not on who typed the code. Without a clear work-for-hire or IP assignment clause, a developer can retain rights even after full payment. Always confirm ownership terms in writing before the project starts, not after it finishes. What if my developer refuses to hand over repository access? Treat that as a serious warning sign, not a technicality to work around. Ask why, in writing, and compare the answer against your contract's IP and delivery terms. If there is no reasonable answer, involve a lawyer before paying any further invoices. Is it normal for a developer to keep the code on their own GitHub account? It happens often, but it should not be treated as normal or acceptable for a finished, paid-for project. Ask for ownership to be transferred to an account you control as a condition of final payment, not as an afterthought once the relationship has ended. How do I check if a deployment login actually works? Log in yourself using the credentials you were given, then make a small, reversible change, such as updating a text field, and confirm it deploys successfully. A login that has never been tested by anyone other than the original developer is not a verified handover. Should a maintenance contract list every possible scenario? No contract can list every possible scenario, and trying to write one that does usually wastes everyone's time. Instead, make sure it clearly states what response time and cost apply to anything not explicitly covered, so an urgent fix never becomes a surprise negotiation.