Most small businesses hire a contract developer, freelancer, or agency to build something — a website, an internal tool, a customer-facing app — and focus entirely on the finished product. That's understandable, but it leaves out a set of things that matter enormously later: when the system needs a fix, when the developer becomes unreachable, or when you want to switch to someone else.
Here's what to ask for before or during the project, not after something breaks.
1. A written specification or requirements document
Before development starts, there should be a document describing what's being built — the features, the user flows, and what "done" looks like. Without this, there's no shared reference for what was actually agreed to, and disputes about scope become a matter of memory instead of a document both sides can point to.
2. Full source code access — not just a finished product
You should have access to the actual source code repository (e.g., a GitHub or GitLab repo you own or are added to), not just a compiled application or a login to a hosted instance. If a developer is unwilling to give you this, it's worth asking why before the project goes any further — it's one of the most common ways small businesses end up locked into a single vendor indefinitely.
3. Database design documentation
For anything involving a database, you should get an entity-relationship diagram or at minimum a written description of the tables, what they store, and how they relate to each other. This is what lets any future developer — including one you haven't hired yet — understand your data without reverse-engineering it from scratch.
4. Deployment and infrastructure access
Know who owns the hosting account, the domain registration, and any third-party service accounts (payment processors, email providers, cloud infrastructure). These should be registered under your business's ownership, not the contractor's personal account — otherwise you're one dispute away from losing access to your own systems.
5. API documentation, if there's an API
If the system talks to other services or exposes endpoints for a mobile app or integration, get documentation of what those endpoints do and how they're authenticated. Undocumented APIs are one of the most time-consuming things to reverse-engineer later.
6. A basic operational handoff
Ask for a short written summary of how the system is deployed, what dependencies it relies on, and what routine maintenance (if any) it needs. This doesn't need to be elaborate — a page or two is often enough to save a future developer days of investigation.
Why this matters more than it seems to at the time
None of this changes how the finished product works on day one. It changes what happens on day 400, when something breaks, the original developer isn't available, and someone else — possibly us — has to figure out what's actually running before it can be fixed. Every one of the items above is the difference between a same-week fix and a multi-week reverse-engineering project.
What actually happens if you don't have this
This isn't hypothetical — it's the pattern we see over and over when we're brought in after the fact. Here's how it actually plays out, concretely, over time.
No documentation
The first time something breaks, whoever looks at it has to reverse-engineer the system before they can even start fixing it — reading code line by line, guessing at intent, testing changes cautiously because nobody knows what else depends on what. A fix that would take an hour with documentation can take days without it, and the invoice reflects that difference. Over time, whoever's responsible for the system becomes afraid to touch it at all, so small bugs pile up unaddressed and workarounds get bolted onto workarounds. Eventually the system becomes so opaque that the only realistic option left is a full rebuild — the exact outcome documentation was supposed to prevent in the first place.
No source code access, and no clear license or ownership
This one is more serious. If you don't have the code, and there's no written agreement establishing that you own it, only the original developer can touch your own software — and they know it. In practice, that plays out as:
- Every future change gets priced as if you have no alternative — because you don't. A five-minute text change can suddenly cost hundreds of dollars, because there's no competing quote possible.
- If the developer becomes unreachable — changes jobs, shuts the business down, stops responding to email — the software freezes exactly where it is. It can't be patched when a security vulnerability is discovered in a library it depends on. It can't be updated when a payment processor changes its API and breaks checkout. It can't be adjusted when the browser or OS it targets moves on. It keeps running as-is until something outside your control breaks it, and then it just stays broken.
- If you eventually try to switch developers, the new one is starting from a compiled binary or a live website, not source code. That usually means a quote for a full rebuild rather than a migration or a fix, because there's nothing to hand off — the new developer has to reverse-engineer your own software from the outside before they can touch it.
- During a security incident, nobody can audit what the software actually does, because nobody but the original author can read it — which is exactly the wrong time to discover that.
- If you're raising investment or going through an acquisition, technical due diligence surfaces this immediately. Software with no clear code ownership, no documentation, and no ability to demonstrate what it does is a common, fixable-in-advance reason deals get delayed, repriced, or walked away from.
- Ownership can be legally ambiguous even though you paid for the work. "Work made for hire" isn't automatic in every contract or jurisdiction — without it spelled out in writing, you may not actually own the software you paid to have built, even years later.
None of this shows up on day one, when the software works and everyone is happy with it. It shows up on the day you need to move fast — a security patch, a new hire who needs to make a change, an investor asking questions — and discover you can't.
If any of this sounds like where you are right now — missing documentation, unclear code ownership, a developer you can no longer reach, or you're just not sure what you actually have — get in touch. We can help you figure out exactly what's missing, what your realistic options are, and whether it's worth reconstructing documentation for an existing system versus starting fresh. If you're about to sign a new contract, we can review it before you do.