You Don't Need to Understand Code, But You Need to Know This Before Paying a Developer

A lot of clients who come to me tell a similar story: they'd already paid a developer or software house before, the system did get built, but once they wanted to add a feature, switch who was maintaining it, or even just find out where their own data actually lived, none of it turned out to be as simple as they'd assumed.

You don't need to understand code to avoid that. You just need to know what to ask before you pay, not after.

The thing that gets missed most often: who holds the code

This is a question rarely asked upfront, even though it matters the most: once the project is done, does the source code get handed over to you, or does it stay with the developer?

"Handed over" here means something concrete: the code repository lives in your own account (or your company's), not just "you can see it if you ask." If the code stays in the developer's personal account, you don't really own the system in any practical sense, even if you've paid in full. If that developer ever becomes unreachable, you're starting from zero.

The simple question to ask: "Will the code end up in my account, or yours?"

Domain, hosting, and other accounts need to be in your name too

This is a similar problem that gets missed for the opposite reason, it doesn't feel like part of "the code." The domain, hosting, API keys, even the email account used to send notifications, all of it needs to be registered under your name or your company's, not the developer's.

In practice this is simple: if the developer registered these, ask for the login and access to be transferred to you once the project wraps up. If they hesitate or keep putting it off, that's worth paying attention to.

I choose platforms with a wide ecosystem for exactly this reason. In the Damai Sejahtera Metalindo website case study, for example, I picked WordPress because it's used by over 40% of websites worldwide, which means the client can easily find someone else to maintain the site later, instead of being locked into just me.

Documentation: the difference between a system others can pick up and a black box

Even code that's fully in your hands isn't worth much if nobody understands how it works. Documentation is what makes a system something anyone can continue, not just the person who built it.

Reasonable minimum documentation to ask for: how to reinstall or redeploy the system, where credentials and API keys are stored, and a rough outline of the system's main workflows. It doesn't need to be a thick manual, but it needs to be something someone else can actually read, not just comments in the code that only the original developer understands.

Read the pricing details: what's included, and what becomes an extra cost

The price quoted is usually clear as a number, but not always clear in scope. A few things that tend to surprise people later:

• Revisions. How many rounds of revision are included in the price, and is anything past that billed hourly or as a new package?
• Running costs. Hosting, domain, and API costs are usually separate and ongoing, not a one-time payment. Get that clear upfront, not as a surprise on the first bill.
• Scope changes. If a feature gets added partway through, how is that cost calculated?

There's no universally right or wrong answer to these questions, but you deserve to know the answer before signing, not after.

Maintenance after launch: who's responsible if something breaks

"Done" means something different for software than it does for a physical product. There's usually a warranty period for bug fixes, typically a few weeks to a month after launch, and after that there's usually a choice: continue a maintenance contract, or go it alone.

What matters isn't which option is better, it's that you actually have a choice at all. This loops back to code ownership and documentation above: if those two are in order, you're free to stay with the same developer or move to someone else.

How to check a portfolio and references that are actually real

A portfolio that gets shown to you has usually already been curated to look its best, which is fair enough. What's more useful is asking to see a project that's still running today (not just a screenshot), and if possible, talking directly to that client about what the process was like, not just the end result.

Warning signs worth watching for

• Won't explain technical decisions in plain language, as if it has to stay a mystery.
• No written agreement at all, everything is just verbal promises or chat messages.
• Asks to be paid in full upfront before any progress can be checked.
• Dodges questions about code ownership or documentation like the ones above.

Any single one of these might not be a dealbreaker on its own. But if several show up together, that's reason enough to pause and reconsider.

Wrapping up

You don't need to become a developer to avoid the problems above. You just need the nerve to ask these questions upfront, before the money changes hands, rather than after the system is built and you realize you never really had control over it.

If you're about to start a project and want to know what other questions are relevant to your specific situation, tell me about it first, and I'll help you think it through from the paying side of the table, not the building side.