If AI Rewrites It, Can I Just Switch Stacks? Three Switches in 12 Days
Over 12 days I moved the backend from Spring Boot to Go and switched mobile stacks three times, to check whether the switching cost is really zero
Four days in, I didn’t like the stacks on either project, the disclosure-summary service or the legislative-activity tracker. If AI does the rewrite, choosing a stack becomes a reversible decision, and I spent 12 days testing that hypothesis by switching backend and mobile stacks. What was at stake was whether the switching cost is really zero.
What I set out to do
Four days into the project, I didn’t like the stack. The backend had started on Spring Boot, but the container was heavy, and running several services at once on the Mac mini left memory tight. Mobile was a Capacitor-wrapped webview, and it didn’t feel native.
Normally I would have put up with it. A rewrite is a multi-day job. But this time I thought differently.
“You’re the one who’d rewrite the frontend anyway. Why is that a burden for a solo developer?”
If AI rewrites the code, choosing a stack becomes a reversible decision. Then there’s no reason to pick perfectly from the start. I tested this hypothesis for 12 days.
How I asked
Backend: I switched two projects on the same day. Both were done in the afternoon of Apr 16. The legislative-activity tracker committed its Go migration at 1:35 p.m. and deleted Spring Boot at 2:20. Forty-five minutes. The disclosure-summary service rewrote at 2:33 and deleted at 2:57. Twenty-four minutes. Once the migration pattern was established on one, the other followed almost at copy level. The second one cost half as much, and that’s the clearest gain from this experiment.
Mobile: I switched three times. Capacitor did not last. I stood up the iOS project at 1:12 a.m. on Apr 15 and moved to React Native at 2:37 p.m. the same day. Half a day. From React Native to Flutter took Apr 24 to 26. Third stack in 12 days.
Same for UI. The map screen of the legislative-activity tracker went through sixteen commits between 8:36 p.m. and 10:38 p.m. on Apr 16. It went from a map drawn off real geographic data to a cartogram, then to a grid cartogram, and finally to grid blocks all the way down to the district level.
A cartogram is a map where regions are sized by data rather than by actual land area. It is the blocky map you see on election night. Assembly seats follow population, so drawing by area shrinks Seoul to a dot and hides exactly where the representatives are. So I threw the area away.
If each had been a multi-hour job, I would have stopped at the first.
Where it broke
The switching cost was not zero.
Rewriting the code was definitely fast. The problem was everything that wasn’t code. Build config, CI, the deploy pipeline, differences in library ecosystems, and the fact that I didn’t know the stack. Moving to Flutter meant relearning even how to read a widget tree. AI writes the code, but I do the review. Reviewing code in a language you don’t know isn’t review; it’s approval.
And the third switch didn’t have a reason as clear as the second. Moving to React Native had a definite reason, Capacitor’s webview limits, but moving to Flutter was closer to “this seems like it’d be better.” As rewriting got cheaper, the decisions got looser.
How I fixed it
Here’s the rule I’ve settled on for now.
OK to switch when I can write the reason in one sentence, and that sentence takes the form “the current stack can’t do X.” The backend move to Go fits here (memory, deployment simplicity).
Not OK to switch when the reason is “it seems like it’d be better.” The third mobile switch is this.
And if you’re going to make the same switch across multiple projects, doing them together is far cheaper. Moving both backends on the same day was accidentally the right move. Doing the second while the pattern is still fresh costs half as much.
Hooking up Codex around this time to get automatic PR reviews was in the same vein. It was an attempt to reduce, even a little, the state of me merely approving code in a stack I don’t know. That did not land in one go either. At 2:50 p.m. on Apr 24 I added a workflow that ran it through the CLI, fixed it three times, then twenty minutes later deleted that and switched to the cloud integration. The Flutter migration started at 4:26 p.m. that same day. I stood up the review apparatus first and switched the stack after.
Lessons
- If AI does the rewrite, stack decisions become reversible. That’s true. But reversible doesn’t mean “free.”
- The cost isn’t in the code; it’s around it. Build, CI, deploy, ecosystem, and my own learning time.
- Review of code in a language you don’t know becomes approval. The more you switch, the less able you are to verify the code. That’s the real cost.
- If you can’t write the reason for switching in one sentence, don’t. “It seems like it’d be better” is not a reason.
- Batch the same switch together. The second one is definitely cheaper.