Author: anthonygarces

You send the same one-paragraph brief to three developers. The numbers come back nowhere near each other — not a little apart, a lot. One is a fraction of another for what reads, on paper, like the identical project.

You didn’t send different briefs. So why does the number swing so wildly?

They didn’t price the same project. They priced three different guesses about what you actually meant — and the gap between those guesses is where a budget goes to die, usually a few months in, in the form of a change order nobody warned you was coming.

Before any of this: is custom even the right call for what you need? An honest framework for build vs buy answers that question first. This guide assumes you’ve already settled it — and you’re now holding quotes that disagree with each other.

What the spread is actually telling you

A quote isn’t a price. It’s a bet on how much the unwritten parts of your brief are going to cost. The developer with the low number is betting there aren’t many unwritten parts. The one with the high number is betting there are plenty, and pricing in the padding to survive finding out. Neither has seen inside your business yet. Both are guessing — one optimistically, one defensively.

The real project usually sits somewhere between the low guess and the high guess. Almost never at either end. That’s not a comforting average — it means the number you eventually pay depends on how much of the guessing you remove before anyone starts building.

The cost drivers you can actually move

Most of what makes custom software expensive isn’t the code. It’s the parts of the job nobody wrote down. Four drivers account for most of the swing between quotes — and all four are yours to move, before a single line gets built.

Scope clarity

“We need a booking system” is not a scope. It’s a category. A developer pricing a category has to guess at the details — how many staff, what happens on a cancellation, does it need to send a reminder — and every wrong guess becomes a change order later, billed at a worse rate than the same detail would have cost as a line in the brief. Writing a brief that describes outcomes instead of features is the one hour, before you request a quote, most likely to change what number comes back.

Integrations

Every other system your new software has to talk to — your accounting tool, your booking calendar, a supplier’s ordering platform — is a separate unknown, with its own documentation quality and its own chance of quietly not working the way its docs claim. A project that touches one system is a different project from one that touches five, even when the feature list looks identical on paper.

Edge cases

The happy path — everything filled in correctly, nothing unusual happening — is the cheap 80%. The other 20% is what a refund looks like, what happens when a card expires mid-transaction, what the system does with a customer who somehow ends up with two accounts. Developers who price fast are usually pricing the happy path only. The edge cases show up later, as scope you get told you forgot to mention.

Who owns the accounts

This one is invisible on a quote and expensive later. If a developer sets up hosting, the code repository, and your API keys — the credentials that let two systems talk to each other — under their own accounts “to make things easier,” easier for whom, exactly? That’s a dependency that never showed up as a line item, and its price stays hidden until the day you need to fire them, or they vanish, or “easier” quietly becomes a monthly fee to keep the lights on in their account. Getting the ownership question answered before invoice one won’t change today’s number. It changes what it costs you to ever leave.

What a suspiciously low quote is actually telling you

A number well under the others isn’t a gift. It’s information. It usually means one of three things: the edge cases haven’t been scoped yet and you’ll discover them on your own dime; the number quietly excludes testing, documentation, or deployment and is a partial figure wearing a full one’s clothes; or the plan is a template or no-code tool that will hit a ceiling the day your business does anything slightly non-standard.

None of those three automatically disqualify a quote. A template approach can be exactly right for a simple need. What disqualifies it is not being told which one you’re getting. Ask directly. A developer who can’t say what’s excluded from their own number hasn’t finished pricing it — they’ve finished guessing at it, same as the other two.

How to check it yourself

• Ask every quote for a line-item breakdown, not a single figure. If one won’t provide it, ask why — and treat “trust me” as an answer that costs money later.
• Ask what’s explicitly excluded: testing, documentation, deployment, post-launch support. Silence on this usually means it isn’t included.
• Ask what would make this specific quote go over budget. A specific answer (“if the payment gateway doesn’t behave the way its documentation claims”) is a good sign. A vague one (“if requirements change”) is not.
• Ask whose name the hosting, repository, and API keys will be registered under. If the answer isn’t yours from day one, that’s a cost you’re deferring, not avoiding.
• Compare the three quotes item by item, not total by total. You’re looking for what’s different, not which number is smallest.

Where this pattern comes from, so you can weigh it

Reviewing scope before work starts is a standing part of the job I do now — Senior Principal Lead Architect, 17+ years in IT, time on both sides of that table at different points in a career. That’s a lot of years spent watching the same spread appear, which is rather the point: you don’t have to spend them yourself to know what it means. Two proposals for what’s described as the same system, priced worlds apart, and the gap is never really about honesty. It’s about how much of the unwritten part each side decided to price in, versus find out about later and bill you for.

The fix isn’t finding an honest developer instead of a dishonest one. It’s removing the guessing before anyone puts a number on paper. The brief does that. Nothing else does.

What to do next

If you’re holding quotes that don’t make sense next to each other, you already have what you need to take them apart: compare what’s actually inside each number, line by line. That beats picking the middle one and hoping. And if you want an outside read on whether a scope is realistic before you commit budget to it, get a free project diagnosis. You’ll leave with a straight answer — including an honest no, if that’s the right one.

For how a custom build actually gets scoped and delivered once the brief is solid, see how a custom web application project is built.

Common questions

Why do software development quotes vary so much for the same project?

Because each developer is pricing their own guess about the parts of the brief you didn’t write down — the edge cases, the integrations, who’s covering testing and documentation. Two developers can read an identical paragraph and price two different projects, because they’re each filling the gaps differently. The variance closes considerably once the brief specifies outcomes, users, exclusions, and what happens when something goes wrong — at that point, the quotes are finally pricing the same thing.

Is a fixed-price quote safer than an hourly one for custom software?

Not automatically — each shifts a different risk onto a different party. Fixed price puts the risk of a scope overrun on the developer, which is why a careful one prices in a buffer for the unknowns before quoting. Hourly puts that risk on you, which is fine if the scope may genuinely evolve but expensive if there’s no cap and no regular check-in on hours burned. Which one actually protects you depends on how well-defined the scope already is going in — vague scope makes both arrangements risky, in different directions.

What should be included in a custom software quote besides the build itself?

Testing, documentation, help getting deployment and hosting set up, and clarity on who owns the code repository and credentials once the project ends. A quote missing these isn’t necessarily dishonest — some developers price them separately on purpose — but it is incomplete, and the missing pieces have a habit of reappearing later as change orders billed at a worse rate than if they’d been scoped from the start. Ask what’s excluded before you compare the number to anyone else’s.

Should I go with the lowest quote I received?

Not automatically. A quote that’s well below the others usually means one of three things: the edge cases haven’t been fully scoped yet and will surface later as change orders; the number quietly excludes testing or documentation; or the plan is a template or no-code approach, which may be entirely appropriate for a simple need but should be disclosed as the plan, not discovered later. None of those three automatically disqualify the low quote. What costs money is treating the smallest number as the safest one without asking what it leaves out.

Every inherited or aging website eventually asks this question. And almost everyone answering it has a reason to prefer one outcome. The developer quoting the rebuild profits if you rebuild. The developer who has patched your site for years profits if you keep patching it. You’re usually the only person with no stake in which answer is true — which makes you the right person to decide it, once you have a way to check the answer yourself.

This is not a quiz with a score at the end. It’s a genuine decision tree: some conditions point one way, some the other, and some honestly can’t be answered without someone opening the code and looking — including the one nobody selling a rebuild wants to admit is possible. The sorting below is the part you can hand off. The call stays yours.

Signs that point to rescue

Read these against your own situation and count how many land. They tend to mean the existing system is worth keeping and repairing.

• The problem is specific and nameable — a broken checkout, an expired credential, one plugin conflicting with another — rather than “everything feels wrong.”
• You have access to the code and its version history, even if messy. A traceable history means the system can actually be understood and fixed.
• The underlying platform still fits the business — you’re not forcing one that has outgrown its tools to keep living on them. The problem sits on top of the platform, not underneath it.
• Staff and customers already know how to use the site, and the workflows work. The problem is technical, not a mismatch between system and business.
• The list of known issues is short enough to fit on one page.

Signs that point to rebuild

These tend to mean patching the system is spending money to delay a cost that’s coming regardless.

• Nobody can explain why the system was built the way it was, documentation is missing, and the version history is gone. You’d be maintaining a black box, not a known system with a bug in it.
• The technology underneath is no longer maintained — no security patches, no active support, a framework nobody building new software chooses anymore. Patching a dead foundation buys months, not years.
• The list of known problems keeps growing faster than anyone is fixing them — a system in active decay, not one with a fixed, containable list.
• The business has outgrown what the platform was ever built to do. That is a sign of growth, not of a bad decision back then. You wouldn’t be fixing a broken version of the right system. You’d be maintaining a working version of the wrong one.
• Every previous “fix” has been a patch on a patch — each one sensible with the information available at the time — and the accumulated complexity is now the actual problem, separate from the original bug.

Where the honest answer is “you cannot know yet”

This is the category most decision guides skip, because “get an audit” is less satisfying than a confident yes or no. It’s also, often, the correct one.

• You do not have access to the code, the hosting, or a clear picture of what’s running. Nobody can judge whether something is repairable without seeing it.
• The site mostly works but fails in ways nobody can explain. Intermittent, unexplained failures are exactly where a guess is expensive and a proper look is comparatively cheap.
• Different developers have told you different things — one says patch it, one says start over — and neither has shown their reasoning in a way you could check.
• Nobody has assessed whether the site is currently secure, and the honest answer is “no one has checked.” Not a real answer either way.
• Every cost comparison you’ve seen came from a single source with an obvious reason to prefer one outcome.

If two or more of these are true, the step that protects you is a technical audit before either decision — not because an audit is always necessary, but because guessing here tends to be the expensive path, not the cautious one.

The conflict of interest nobody says out loud

A developer paid to rebuild your site has a financial interest in the rebuild being right. That doesn’t make the recommendation wrong — rebuilding is sometimes the right answer, and a developer with integrity will say so even though patching would cost you and them less. But the incentive is real, and pretending otherwise helps only the person holding it. The same conflict runs the other way: a developer paid hourly to keep patching has every reason to keep recommending another patch.

This applies to Anito exactly as much as anyone else quoting you a rebuild. Any developer with a rebuild to sell — including this one — has a reason to prefer the more expensive answer. I can say all the right things about it. That doesn’t make the conflict disappear, and you shouldn’t let me saying it stand in for checking. What protects you is separating the diagnosis from the person who profits from the recommendation: ask what’s specifically wrong before you ask what it costs to fix. Get the findings in writing before you get a number. If the findings and the quote arrive together, from the same person, with no room to think between them — that’s worth noticing before you sign anything.

The part that stays invisible from the outside

I spent two years doing senior WooCommerce work at WooAssist — more often than not, rescue work. Stores built by someone else, handed over because checkout had stopped working, or the person who understood the customizations was long gone. Some were a fast fix: one expired payment credential, one plugin update that had quietly broken something else. Others had been patched by enough people, in enough different ways, that patching it again would cost more and leave something more fragile than starting clean. The part of that worth handing you is this: from the outside, both looked identical — a store with a checkout problem. So if you can’t tell which one you have, that is not a gap in your judgment. The difference only became visible once someone opened the code and looked.

A recommendation you cannot check is not worth much more than the guess it replaced.

Anito’s own rescue process follows that lesson: the audit and its findings come before any quote, in writing, so you can take them elsewhere for a second opinion if you want one. That describes the process, not a result — there’s no finished client engagement yet to point to as proof it worked. For the math on what a struggling site is costing you while you decide, see is your website costing you sales. For what a rescue engagement covers, start at website rescue and repair.

If you’re somewhere in the “cannot know yet” column above, the diagnosis is free — you get findings in writing before anyone asks you to choose between rescue and rebuild.

Common questions

Is paying for a technical audit worth it, or is it a way to charge me before the real work starts?

That is a fair suspicion and you should keep it — including about anyone who recommends an audit and then quotes the build, which is this guide’s own position. Here is how to tell the difference without trusting anyone: an audit is real when the findings land in your hands as a document, written plainly enough that you can take it to a different developer and get a competing quote off it. Then set the price against the decision it protects. Put the audit fee next to the cheaper of your two options and see what fraction of it you are being asked to spend. If it is a small slice of a number you would otherwise be guessing at, it is the cheap part of the month — and if the findings cannot leave the room, you were not buying an audit.

How do I get a second opinion without damaging the relationship with my current developer?

Tell them you are doing it, and give the reason in one sentence: the decision is big enough that you want a written picture of the system from someone with nothing to sell on either side. You are not auditing their work — you are buying a description of what you own, which is a reasonable thing to hold no matter who built it. A developer who is confident in what they built tends to be relaxed about this, and some will hand over the access before you finish asking. If the reaction is that a second look is unnecessary or insulting, that is information you did not have this morning, and you can file it without acting on it today.

If we rebuild, do we lose our content and our Google rankings?

Content moves. What damages rankings is page addresses changing while nothing connects the old ones to the new ones, and that job has a name and a public standard — Google Search Central publishes a site-move guide covering URL changes, so you can read what good looks like before anyone quotes you against it. Ask for the redirect map, the list pairing every existing page address with where it lands after launch, as a named deliverable with a date on it, agreed before the build starts rather than in the week of launch. Then ask which pages are being dropped on purpose, because a rebuild that quietly removes pages is a different decision from one that moves them, and that decision is yours rather than theirs.

Our site still works but it is several years old. Is age on its own a reason to act?

No. A site doing its job on software that still receives security updates can stay where it is for a long time, and replacing it because the number of years feels large is spending money on a feeling. The trigger is support, not age: find out which version of the underlying platform you are running, then check it against the maker’s own list of supported versions, which the mainstream platforms publish openly. If your version has fallen off that list, the clock is real and it has nothing to do with how the site looks. If it is still on the list and the site does what the business needs, the honest answer is that you have nothing to do this quarter — and anyone saying otherwise should have to name what is specifically failing.

An automation ran. Something happened — a record updated, an email sent, a value changed. You weren’t there, and nobody asked your permission first. The only way to know what actually took place is the log. Reading one doesn’t require technical skill. It requires knowing what a log is supposed to tell you — and noticing when it doesn’t. Both of those are on this page.

What a log entry actually is

Strip away the technical framing and a log entry is a sentence: at this time, this happened, because of this, and here’s what it produced. A system that can’t produce that sentence for something it did is not accountable for what it did. There’s no record for you to check. Only a claim that it behaved.

Four years running platform support at Pantheon put me on the other end of those emergency calls, and most of them came down to one question: what actually happened, and in what order? Sites with a clear record of who changed what, and when, got diagnosed and fixed within the hour. Sites where nobody could reconstruct the sequence took the rest of the day before anyone could even agree on the cause. That pattern took four years to see clearly and takes one paragraph to hand over, so you never have to learn it during your own bad afternoon. The log was never a formality. It was the difference between a fix and a guess.

The five things every entry should tell you

A log entry that’s doing its job answers five questions, every time, for every action. Miss one, and you’re not looking at an audit trail. You’re looking at a partial record with a gap exactly where the risk lives.

1. What triggered it. The specific event that started the automation — a form submitted, a payment received, a document uploaded. Not “the system ran,” but the actual thing that set it off, with a timestamp.
2. What the system decided. The output, in a form you can actually read. Not internal jargon — a plain statement of the result, such as “classified as a billing question” or “total and due date extracted as written on the document.”
3. Its confidence. How sure the system was about that specific decision, as a number or a plain label. A system that won’t say how confident it was in a given case is asking you to trust every decision equally — which isn’t something even the system believes.
4. Who approved it. If a human was supposed to review the action first, the log names that person and records what they decided — approve, reject, or edit. If nobody’s named, nobody reviewed it. Whatever anyone tells you afterward.
5. What changed. The concrete result: the record written, the email sent, the field updated, with enough detail that you could check it against the live system and confirm it matches.

This is the same discipline behind our safe AI automation checklist — that guide is about building a system that produces logs like this. This one is about reading what you’ve already been handed, so you can name what is missing instead of only sensing that something is.

What a log that hides more than it reveals looks like

Some logs are technically logs and functionally useless. The pattern is consistent enough that you can spot it without any technical background.

• Entries that summarize instead of record: a tally of how many items were processed tells you a count, not what happened to any single one of them.
• No timestamps, or timestamps with no time zone given. You can’t reconstruct a sequence of events from a log that won’t say what order things happened in.
• A confidence score that’s always the same number, or missing for exactly the cases the system was actually unsure about.
• “Reviewed by system” where a person’s name should be. A system can’t review itself and call that independent approval — the same self-approval problem covered in what a passing test actually proves.
• Gaps during exactly the hours or days something went wrong — a log that’s thorough on ordinary days and thin during the incident is a record of everything except the part you needed.
• No stated retention period, or one nobody can confirm. A log that disappears quickly can’t be checked once a problem takes longer than that to surface — and you don’t get to schedule a dispute.

A log that summarizes instead of records is not evidence. It is a claim wearing evidence’s clothes.

The three questions to ask when a log looks wrong

You don’t need to diagnose the system yourself. That is the job of whoever built it, and you are entitled to hold them to it. Ask three questions, and listen for whether the answer is specific.

What was the input, exactly? Not a summary — the actual thing the system received. If the answer is vague, the log isn’t tracing back far enough to be useful to you.

Why did the confidence score not trigger a hold? If something went wrong and the system’s confidence was low at the time, ask why that didn’t stop the action from happening automatically. A well-designed system holds low-confidence actions for a human. If yours didn’t, that threshold is missing, or set too loosely.

Who signed off, and can I see their decision separately from the system’s own output? You want a human decision recorded as its own distinct entry — not folded into the system’s output as if the two were the same thing. If the answer blurs them together, there was likely no independent review at all.

Seeing the pattern, not a promise

The same standard is going into Ranex, my own governance kernel for AI-assisted work — pre-release, and not something I’m asking you to adopt here. It earns a mention for one reason: it shows what this standard looks like when someone builds to it deliberately, which gives you something concrete to point at. Every verdict it produces gets written to an append-only, hash-chained journal — a record built so it can’t be quietly edited after the fact once it exists. The tool isn’t the point. The point is that a log worth trusting has to be built to resist being rewritten, not only built to exist — and that is a fair thing for you to ask of whoever built yours.

Anito’s demo lab runs three sandboxed automation patterns built to show this exact structure — trigger, process, human review, output — with every step logged in a plain run record you can read without technical background. It’s a demonstration, not a client result: there’s no finished engagement behind it. It exists so you can see the shape a trustworthy log should have, and know what to ask for — and what to send back — when a system is built by someone else.

If you already have an automation running, and want an independent read on whether its logs hold up to these questions — the diagnosis is free. A straight answer in writing, whether or not anything follows it.

Common questions

Does a small business actually need audit logs, or is that only for regulated industries?

Regulation is what forces the question. It is not what creates the need. The moment something runs without a person watching it — an automation sending email, updating records, moving money — a log is the only way you find out what it did on a day you were not looking. Without one, a customer dispute comes down to your memory against theirs, and memory is not evidence. Regulated businesses were made to build this early; everyone else gets to choose, and the cheapest moment to choose is before the system is built rather than during the afternoon you needed it.

How long should we keep audit logs?

Long enough to outlive the slowest route a problem takes to reach you — and that is a number you already know and your developer does not. Work it out with your own figures: how long can a customer dispute a charge, how far back can a tax authority ask you to go, how long does one of your contracts stay open to challenge? Take the longest of those and keep the logs past it, because a log that expired the month before the dispute arrived is the same as no log at all. Then get the retention period written down and confirmed, since “we keep them for a while” describes a setting nobody has opened.

Who should be able to edit or delete audit log entries?

Nobody who can perform the actions being recorded. If one account can change a record and then remove the line saying it changed the record, the log has stopped being independent evidence and become a note that happened to survive. Ask two things: who holds permission to delete or edit entries, and whether deleting one leaves a trace of its own. The answer you want is that entries are added and never altered, delivered as a flat no with a reason behind it — not as “why would anyone do that?”

The automation has no log at all. What do I ask for?

Ask what it would cost to add one, and ask for it inside the next piece of work rather than as a project of its own — recording what a system did is a smaller job than building the thing that does it. Hand over the five items listed above as the written requirement, because “add logging” gets built as whatever is quickest, and quickest is a line that says the automation ran. Ask where the log will live and who can read it without going through the developer, since a record you cannot reach on a bad afternoon is not yours in any way that helps you. And if the answer is that the system cannot record what it did, you have learned something about the system rather than about the log.

Every developer uses AI now. Ask “do you use AI to write code” and you get a yes almost every time — which tells you nothing you can act on. What you want to know is what happens between the AI generating something and that something reaching your live system. That gap is where a good developer looks nothing like a careless one — and it is something you can check without reading a line of code.

You don’t need to read code to check this. I’ve spent a lot of my 17-plus years in IT judging whether someone else’s technical decision holds up — long before AI made that call both more necessary and easier to fake. What came out of those years is a shortlist, and it’s yours: five questions, plus the patience to hear a specific answer instead of a comfortable one. Ask them before you sign anything. Ask them again once work starts.

Why “they use AI” stopped being the right question

A few years ago, using AI to write code was worth flagging on its own. That moment has passed. The tools write real, working code quickly, and most developers now use them daily. Refusing to work with anyone who touches AI narrows your options and leaves the actual risk exactly where it was.

The risk was never the AI. It’s what a developer does, or doesn’t do, after the AI produces something. Ungoverned AI use produces code that runs today and breaks in three months, for reasons nobody can explain — because nobody tracked what changed. Governed AI use looks identical from the outside. That is not a failure of your judgment; it is the nature of the thing. The two stay identical until something goes wrong. Then the difference is the whole story.

The five questions

Ask these in order. You are not being tested on technical knowledge here — you are listening. A developer who is doing this well answers all five plainly, without jargon and without defensiveness.

1. What do you personally check before you accept what the AI wrote?

Why it matters: an AI model generates code confidently whether or not it’s correct. Confidence is not a signal you can trust from something that has never once meant “I’m not sure.” Somebody has to be the actual check — a real, describable process you can hear described out loud. Not a vague feeling of “it looks right.”

• A good answer sounds like: something specific — small, reviewable chunks of work, a manual read-through of the actual change before it merges, a defined set of checks that have to pass first.
• A bad answer sounds like: “I read it over,” with nothing further when you ask what that means. Or “the AI is pretty reliable now” — as if reliability were a reason to stop checking.

2. How do you know it is tested, not only that it runs?

Why it matters: code that runs without errors, and code that does the right thing, are two different facts. AI-generated code is especially prone to the first without the second — it’s fluent, not necessarily correct. If you want the longer version, what a passing test actually proves covers it: a green checkmark only tells you the assertions someone wrote ran clean.

• A good answer sounds like: naming the specific behaviors that get checked — the payment going through, the form saving correctly — and being upfront about what isn’t covered yet.
• A bad answer sounds like: “Don’t worry, it’s tested.” That sentence is reassurance, not evidence. A developer with a real answer won’t need to fall back on it.

3. Who checks the work besides you?

Why it matters: if the person who wrote the prompt, generated the code, and ran the tests also decides it’s good enough — that is not independent verification. It’s one person satisfied with their own output, which may be true, and still isn’t proof. A self-approved result looks identical to an independently checked one, which is exactly why you have to ask rather than look.

• A good answer sounds like: a named second reviewer, a defined review step, or a separate check that has to sign off before anything ships — something outside the same head that wrote the prompt.
• A bad answer sounds like: “I’m pretty careful, so it’s fine” — an answer about the person’s character, not about the process.

4. Tell me about the last time the AI got something wrong.

Why it matters: anyone doing real work with AI-assisted development has a story. It happens. A developer who claims it never has is either not paying attention, or not being straight with you. You are testing candor here as much as competence — and candor is something you can already judge in any field.

• A good answer sounds like: a specific, slightly uncomfortable story — what broke, how it was caught, what changed in the process afterward so it doesn’t happen the same way twice.
• A bad answer sounds like: a flat denial, or a generic answer with no detail, delivered a little too smoothly.

5. If the AI wrote most of this, can you explain what it did without saying “the AI handled it”?

Why it matters: this is about ownership, and the ownership in question is yours. If your developer can’t explain the logic in plain terms, the next one won’t be able to either — and there will be a next one, by choice or because the first left. Code nobody can explain is a liability wearing the shape of an asset.

• A good answer sounds like: a plain-language walkthrough of what the system does and why, delivered without hand-waving, even if you don’t follow every technical detail.
• A bad answer sounds like: “it’s complicated,” or a retreat into jargon the moment you ask a follow-up question.

A bad answer is not a lie. It is reassurance standing in for a process that was never built.

Why you can judge this without reading code

None of these five questions require you to know anything about code. They require the judgment you already use when a supplier explains a delay or a candidate explains a gap: the difference between a specific answer and a comfortable one. A developer who has genuinely governed their AI use will answer plainly — sometimes with an example that’s a little embarrassing to tell. One who hasn’t will reach for reassurance instead, and you will hear it.

This matters more, not less, as AI writes a larger share of the code you pay for. Speed was never the problem. Speed with nobody checking is — and that’s as true of AI-written code as it has always been of human-written code. For the fuller picture of what “tested” should mean, read what a passing test proves — and what it doesn’t. For what a properly structured engagement looks like, see how Anito structures ownership from day one.

If you want a second opinion on work you’ve already been handed — code, a quote, a claim that “it’s tested” — the diagnosis is free. You get a straight answer in writing, whether or not you ever hire Anito for anything after that.

Common questions

Should I refuse to hire a developer who uses AI to write code?

Refusing costs you good people and leaves the actual risk exactly where it was, because the risk was never the tool. There is one restriction worth writing down, and it has nothing to do with their keyboard: ask where your code and your customer data go when they use it. Whether anything you send gets retained, or used to train the next version of the model, depends on which account tier they are on — and every major vendor documents that on its own site. So the question to ask is which account they use, and then check the answer against the vendor’s page rather than against their reassurance.

My developer says they review everything the AI writes. How do I check that without reading code?

Pick one change that went live recently and ask them to walk you through it: what the AI produced, what they changed about it, who else looked at it, and what the checks said before it shipped. Then ask the harder one — what was the last thing the AI wrote that you threw away? Someone who genuinely reviews has rejections and remembers them, and the answer arrives with detail because it cost them an afternoon. Ask for the walkthrough in writing rather than in a meeting. A claim behaves differently once somebody has to type it.

Can I find out whether AI wrote the code I already paid for?

Not reliably. Detection tools for code produce a confident-looking number with no way for you to check it, and one careful human edit changes the answer — so anyone quoting you a percentage is guessing. Here is the part that puts you back in control: it stops mattering. What you need to know is whether the thing can be maintained, and that you can check without knowing who typed it. Ask whoever holds it now to explain any one part of it in plain language, ask to see the history of what was changed and when, and ask what happened the last time someone made a small change — whether anything unrelated broke. Those three answers tell you what a detection score never could.

What should our contract say about AI-written code?

Do not try to ban the tool. You would be policing something you cannot see, and paying someone to do the policing. Write down the outputs instead, because those you can hold up and check: a written record of what changed and why, a named human who signs off on each change before it reaches your live system, and the code plus its full history delivered into accounts in your company’s name. The handover clause is the one that quietly decides what leaving costs you later, so read it before you read the pricing, and get the account names spelled out rather than described. A clause you cannot verify without trusting the person it constrains is decoration.