Change request: how to change a software build mid-project

The controlled way a non-technical founder changes what’s being built, before the change turns into scope creep or a surprise invoice.

Daniel runs a small fintech in Austin. Six weeks into building his lending dashboard, he watched a sales demo go sideways because the app showed dollar amounts but not the dates money actually moved. Obvious fix. He dropped a line in the project Slack: “Hey, can we also show the settlement date next to each amount? Should be quick.” Two thumbs-up emojis came back. He moved on.

Three weeks later the invoice landed eleven hundred dollars over the estimate, the launch had slipped by nine days, and Daniel had no idea why. The “quick” settlement date meant pulling a field the system had never stored, which meant a change to the database, which meant re-testing every screen that touched a transaction. None of that was visible from where he sat. He’d approved a small picture and paid for a large one.

The thing that would have saved him is unglamorous and almost never explained to the person who needs it most. It’s called a change request.

What a change request actually is

A change request is a short, written record of a change to what a software team is building, raised after the work has already started, that states what’s changing, why, and what it costs in money and time before anyone touches the code. It is the door through which every mid-project change is supposed to walk.

That’s the whole idea. You agreed to build A. Now you want A-plus, or A-but-different. A change request is how that new decision gets named, priced, and approved on purpose, instead of absorbed quietly and discovered later.

Most of what you’ll read about change requests online is written for corporate IT departments managing changes to systems already running in production, or for project managers living inside a tool like Jira or monday. That framing is real, but it’s not yours. You’re not approving a server patch. You’re a founder who commissioned a build, can’t read the code, and needs a way to steer it without flying blind. Same artifact, completely different stakes.

Change request vs scope creep: the same change, controlled or not

Here’s the distinction that matters more than any definition. A change request and scope creep are frequently the exact same change. The only difference is whether it went through a door you control or a crack you didn’t see.

Daniel’s settlement date was a change request that never got written down. Because it stayed a Slack message, nobody stopped to price it, nobody flagged the database work, and the cost showed up as a mystery line on an invoice instead of a number he approved in advance. That’s scope creep. Not because anyone was dishonest, but because the change had no front door, so it came in through the wall.

Run the same moment with a change request and it looks different. Daniel asks for the settlement date. The team writes back: “That field isn’t stored today, so this is roughly a day and a half of work plus re-testing, about twelve hundred dollars, and it pushes the milestone by two days. Want us to proceed?” Now Daniel decides. Maybe the demo is worth it and he says yes with his eyes open. Maybe he says “park it until after launch.” Either way, he’s the one who chose, and there’s no surprise on the invoice.

The change request doesn’t prevent change. It makes change a decision instead of an accident. That is the entire value, and it is worth more to a non-technical founder than to almost anyone else in the room, because you’re the one person who can’t see the cost coming on your own.

What goes in a change request

A good change request is short. If it runs longer than a page, the change is big enough to be its own mini-project and should be scoped like one. For an ordinary change, you want five things, and you should be able to read all five even though you can’t read code.

What’s changing, in plain language. One or two sentences a normal person understands. “Add the settlement date next to each transaction amount on the dashboard.” Not “modify the transaction serializer.” If you can’t follow the description, that’s a signal, not a detail to skip past.

Why. The business reason, in your words. “Sales can’t close demos without it.” This matters because it’s the thing you’ll weigh against the cost. A change with a weak reason and a real price is the easiest “no” you’ll ever make.

The cost in money and time. The team’s honest estimate of effort and what it does to the timeline. A change that’s cheap in dollars can still be expensive in days if it blocks other work. You want both numbers.

What it touches. A line on the ripple effect. Does this change one screen, or does it reach into data that other screens depend on? This is where the “small change, large cost” surprises hide, and a good partner will tell you before you ask.

Your decision. Approved, rejected, or parked, with a date and your name on it. A change request without a recorded decision is just a conversation, and conversations don’t hold up when memories disagree two months later.

That’s it. No software required. A shared doc with a running list of these does the job for a build that isn’t enormous. The discipline lives in the habit, not the tool.

The four kinds of change you’ll actually face

Corporate change management splits requests into categories like “standard,” “normal,” and “emergency.” Useful for an IT operations team. Not the cut that helps a founder decide. The four kinds you’ll actually run into are these.

The clarification. You’re not really changing the plan; you’re discovering that the plan was vague. The original project scope said “user can export their data” and now you’re learning that “export” could mean a CSV, a PDF, or a full API. This shouldn’t cost extra if the vagueness was in the spec, and a fair partner will treat it as filling in a blank rather than a paid change. Watch how a team handles these. It tells you a lot.

The addition. Genuinely new work nobody planned. A new screen, a new integration, a new rule. This is a real change request with a real price, and it’s the most honest kind. You wanted more, more costs more, everyone understands the trade.

The reversal. You’re undoing or redirecting something already built. These are the ones founders underestimate most, because tearing out finished work and rebuilding it is often more expensive than building it right the first time would have been. A reversal can cost more than the original feature did. Knowing that in advance changes how carefully you lock decisions before the work starts.

The “while you’re in there.” The dangerous one. “Since you’re already touching the dashboard, can you also…” These feel free because the team is already in the neighborhood. Sometimes they genuinely are cheap. Often they’re a second change wearing the first one’s coat, and three of them stacked together are how a two-week slip becomes a two-month one. Make each one its own line, even when it feels small.

Who raises one, and why it should usually be you

In the corporate version of this, anyone can file a change request and a change board reviews it. On your build, the question is simpler and the answer is mostly you.

Changes originate from two directions. Some come from you, because the market moved or a customer asked or a demo exposed a gap. Some come from the team, because they hit something the plan didn’t anticipate. Both are legitimate. What you want is a standing agreement that neither side acts on a change of any size without it becoming a written request first. The developer doesn’t quietly add the thing you mentioned in passing. You don’t expect work you never approved.

The reason it should usually route through you is not control for its own sake. It’s that you’re the only person who can weigh a change against the things the team can’t see: the runway, the fundraise timeline, the customer you’re trying not to lose, the launch date you promised the board. A developer optimizing for a clean codebase and a founder optimizing for a Series A will make different calls on the same change, and the founder’s call is the one that should win. A change request is what puts that decision in your hands instead of in a Slack thread nobody re-reads.

This is also the clearest test of whether you’re working with a tech partner or a black box. A partner raises change requests unprompted, prices them honestly, and sometimes talks you out of one. A black box absorbs your offhand comments, bills you for them later, and calls it what you asked for.

How a change request gets priced, and the “small change” trap

The single most expensive phrase in software is “it’s just a small change.” Not because teams lie about it, but because “small” describes the picture in your head, and the picture is the cheapest part.

A change you can describe in one sentence can require touching the data underneath, the logic that processes it, every screen that displays it, and the tests that prove none of it broke. Daniel’s settlement date was one sentence and four layers of work. The visible part, the number on the screen, was maybe an hour. The invisible part was everything that had to move so that hour was safe.

When a change request comes back priced higher than you expected, the right move is not to assume you’re being padded. It’s to ask one question: “What makes this more than it looks?” A good partner answers in business terms you can follow. “The date isn’t stored anywhere, so we have to start capturing it, backfill the old records, and re-check every transaction view.” A bad partner says “it’s complicated” and you learn nothing. The quality of that answer is worth more than the quote itself.

You also want change pricing tied to how you’re already paying. If you’re on a fixed-price contract, change requests are where the real negotiation lives, so the definition of what counts as done on the original scope matters enormously. If you’re on time and materials, every change is already metered, and the change request is mostly about you keeping the running total visible to yourself. Either way, the request is the moment the abstract cost of “more” becomes a real number you can accept or decline. For a fuller picture of why those numbers move the way they do, our breakdown of what an app actually costs to build walks the same ground from the budget side.

The change-request habit that keeps a build honest

None of this requires a process diagram or a tool subscription. It requires one habit, agreed on out loud at the start of a project: no change of any size happens without a written request and a recorded decision.

Say it in the first meeting. “If either of us wants to change anything once we start, it goes in the change log first, gets a price and a timeline, and I approve it before any work happens. Including the small stuff.” A serious partner will be relieved you said it, because it protects them as much as you. The team that resists is telling you something.

The whole agile tradition is built on the assumption that requirements will change, that this is normal and even healthy. The Agile Manifesto makes a point of welcoming changing requirements late in development. But “welcome change” and “absorb change invisibly” are not the same instruction. You welcome change by giving it a front door, a price tag, and your signature. You get burned by change when it has none of those.

Daniel runs his builds differently now. Every change, including the ones that feel too small to bother with, goes in a shared doc with a number and a yes or no next to it. His invoices stopped surprising him. Not because his projects stopped changing, but because he stopped finding out about the changes after he’d already paid for them. The change request didn’t slow him down. It just moved the moment of decision to before the money was spent, where it belonged the whole time.

Frequently asked questions

What is a change request?
A change request is a short, written record of a change to what a software team is building, raised after the work has started, that states what’s changing, why, and what it will cost in money and time before any code is touched. It turns a mid-project change into a decision you approve on purpose instead of a cost you discover later.

What is in a change request?
Five things: a plain-language description of what’s changing, the business reason for it, the cost in money and time, a note on what other parts of the system it touches, and a recorded decision (approved, rejected, or parked) with a date and a name. If it runs longer than a page, the change is big enough to be scoped as its own small project.

What are the four types of change request?
For a founder, the useful cut is by what the change does: a clarification (the plan was vague and you’re filling in a blank, often no extra cost), an addition (genuinely new work with a real price), a reversal (undoing built work, frequently more expensive than the original), and the “while you’re in there” add-on (feels free, often isn’t). Corporate IT uses standard, normal, and emergency categories, which matter less when you’re commissioning a build.

Who can initiate a change request?
Either side can raise one, you or the development team, and both are legitimate. The agreement to make at the start is that neither side acts on a change of any size without writing it down and getting your approval first, because you’re the only person who can weigh a change against the runway, the timeline, and the customer you’re trying to keep.

How is a change request different from scope creep?
They’re often the identical change. The difference is control. A change request goes through a door you manage, with a price and your approval. Scope creep is the same change slipping in through a crack, unpriced and unapproved, until it shows up on the invoice. The request is what turns creep into a choice.