A small budget does not justify a careless backend change. It just forces you to be selective about what you make safe. If you have been asked to add one endpoint to an awkward service, I would fund a narrow, reversible slice before funding a platform rebuild. That position can annoy a team living with bad infrastructure, but a rebuild is a poor bargain when nobody can yet name the failure it must prevent.
A cheap change needs a smaller safety boundary, not weaker safety
Suppose an Express 5 service on Node.js 22 stores orders in PostgreSQL 16, and your task is to expose an order’s external reference through one API endpoint. You can implement the response quickly, but you cannot assume the work ends at the controller: the database column, existing callers, deployment order, and rollback all affect whether the change is safe. Keep the scope to that path, rather than treating every unpleasant part of the service as part of your ticket.
For planning, assume you have 8 engineer-hours before review. That is a budget assumption, not a universal estimate. Spend the first hour tracing the request through the route, service, SQL query, and response serializer. Write down the files and deployed components it touches. If you cannot identify the live query or the client that consumes the response, stop estimating the implementation, because an unknown dependency makes your apparent time saving fictitious.
Read Before You Scope It, Test the Stack’s Hidden Costs before pricing a migration, because authentication, deployment, and data behavior can cost more than the code change. I would apply that warning narrowly here: investigate the stack behavior that intersects this endpoint, not every component you might someday replace. A full inventory can consume the whole budget while leaving the requested behavior untouched.
Define the boundary in terms you can verify: the old response remains valid; the new field is nullable; a failed deploy does not require restoring a database backup; and an operator can stop serving the new field without deleting data. Those conditions are more useful than “minimal change,” because another developer can test each one. They also tell you what not to do. I would not rename the existing response field while adding the new one, because a caller still using the old name could break even if your new endpoint test passes.
On a small budget, “properly” should mean that the specific risk you introduce has an owner and a check. For this change, that means reviewing the migration with someone who knows the production table, exercising both old and new response shapes, and naming the person who can disable the endpoint after release. It does not mean adopting a new framework, adding a service boundary, or promising to clean up every query nearby; none of those pays for the immediate compatibility risk.
A funded rebuild only wins when the slice cannot contain the risk
Here is the comparison I would put in the ticket. Budgeted vertical slice wins when the behavior fits behind the existing API, the schema can expand without changing old readers, and the service can be deployed independently of its callers. Its cost is a limited set of tests, a reversible release, and some remaining platform debt. Funded platform repair wins when a shared component prevents a safe slice—for example, deployments replace every service at once and cannot be rolled back, or one database write path silently changes records used by many endpoints. Its cost is a separate project: migration planning, dual-running or coordinated releases, broader regression checks, and delayed feature delivery.
Those are different purchases, so I would not describe the rebuild as the “proper” version of the endpoint ticket. If the underlying release process is unsafe, request funding for release-process repair with its own acceptance criteria, because hiding it inside a feature estimate makes both efforts hard to finish. Conversely, if a feature slice can be turned off while old behavior remains intact, rebuilding first spends money before proving the rebuild is necessary.
Read Platform rebuild or feature slice Which should a backend dev pick before voting for a rebuild, because the choice deserves an explicit cost comparison. I disagree with treating those options as mutually exclusive commitments: a slice can establish the baseline and reveal the precise platform constraint that merits later funding. The slice must be designed to produce that evidence, though; simply adding code and declaring the platform “fine” would teach the team nothing.
Make the decision with an observable trigger. For example, set a 2-hour investigation limit as a value to tune with your lead. If you cannot demonstrate an additive migration and an independent rollback within that window, report the blocker instead of stretching the feature estimate. The trigger is not “this code feels old,” because age alone does not show that this endpoint cannot ship safely. It is a concrete failed rehearsal: the old application cannot run with the new schema, the deployment cannot be reversed, or the query needs a lock the team cannot tolerate.
As a junior developer, you do not need to approve the budget. You do need to make the trade legible. Bring your lead a short account of what you tested, which condition failed, and how much work each option buys. “We need a rebuild” invites a debate about taste; “the old release fails against the expanded schema, so we cannot roll back the app” gives the team a decision it can act on.
The cheapest useful test checks the release contract
Before writing a large test suite, ask which promises the release makes. For the example endpoint, use a Vitest 3 test with Supertest 7 to check that an existing order still returns the old fields and that an order without an external reference returns a valid response. Use a PostgreSQL 16 database in Docker Compose v2 for the query test if the SQL matters; mocking pg 8 cannot tell you whether the actual column, null handling, or index behaves as expected.
A local HTTP smoke check is useful after deployment, but it should verify a contract rather than merely receiving a connection. If the service already exposes a JSON health endpoint returning {"status":"ok"}, this script can check it; pass a different URL as the first argument when needed:
#!/usr/bin/env bash
set -euo pipefail
body="$(mktemp)"
trap 'rm -f "$body"' EXIT
code="$(curl -sS -o "$body" -w '%{http_code}' --max-time 3 \
"${1:-http://localhost:3000/health}")"
test "$code" = 200
node -e 'const fs=require("node:fs"); const b=JSON.parse(fs.readFileSync(process.argv[1],"utf8")); if(b.status!=="ok") process.exit(1)' "$body"
echo "Health contract passed"
The --max-time 3 setting is a local timeout to adjust for your environment, not a performance target. Run the script from GitHub Actions after starting the service, or run it against a staging deployment; a passing local test alone cannot establish that the deployed configuration works. Keep the endpoint test separate from this check, because a healthy process can still return the wrong order data.
Spend review time where it changes the release decision. Confirm that the migration adds the nullable column before code starts reading it, and that the old application version can still run afterward. If the table is large, ask the database owner how the migration will acquire locks; PostgreSQL’s lock_timeout is a control worth considering because an unexpectedly blocked migration can interfere with live work. Do not copy a timeout from another service without checking its workload.
Record a baseline before release. In an illustrative staging run, suppose 30 requests produce a p95 response time of 180 ms; those are sample measurements from that run, not production guarantees. Repeat the same requests after the change and inspect errors as well as latency. Prometheus request counters and Grafana panels can help if the service already uses them, while OpenTelemetry traces can locate time spent in the database; adding all three for one endpoint would cost more than a bounded change if the team has no existing telemetry pipeline.
A small budget still has to pay for a way back
Decide what “undo” means before merging. An additive database column can remain after an application rollback, so the cheapest safe reversal may be redeploying the old app or disabling the new route. Dropping the column during an incident is a worse default because it destroys data that another release may already have written. Write the rollback instruction in the pull request and have another developer follow it in staging; a plan nobody has tried is only a guess.
“Doing it properly” can fund more than that minimum: a staged rollout, a feature flag with an owner, a tested down-migration where data loss is acceptable, and automated checks across supported client versions. Each addition has an operating cost. A flag, for example, needs a default value, removal date, and someone watching its state; without those, it becomes another branch future changes must test. Choose the larger investment when the number of callers or the cost of a bad response warrants it, not because a checklist says every endpoint needs the same machinery.
Give the release a stop condition. A proposed threshold to calibrate against your service is 5xx errors above 1% for 10 minutes on the changed route. The exact threshold needs tuning because a low-traffic endpoint may not produce enough requests for that percentage to be meaningful. Pair it with a human-readable signal—such as a failed order lookup reported by support—and state who will decide whether to disable the route. That makes rollback an action rather than a vague promise.
Your first concrete move is to trace one request from route to database and write down the old response, the proposed schema change, and the rollback command. Take that page to your lead before asking for a rebuild budget. If the old release survives the new schema and the endpoint can be disabled, ship the bounded slice; if either test fails, you have a specific repair to fund.
