We spent two weeks stuck on a sorting algorithm.
Not a glamorous two weeks. The job was a home feed — the screen you see when you open an app — and the rules had quietly stacked up. Show the freshest things. Respect what the person actually cares about. Never put two posts from the same user next to each other. Then a fourth rule, and a fifth, each one reasonable on its own, all of them fighting each other in combination.
We are not a junior team. We have shipped 40+ apps. And we were tripping over our own feet — every fix to one rule broke another, and the logic had knotted itself past the point where any of us could hold the whole thing in our heads at once.
What untangled it was an AI, working directly inside the project through something called MCP. It cut through that knot in a way that was, frankly, beyond me technologically.
Which is the good news. The rest of this post is the honest version of that story, because the honest version is more useful to you than the triumphant one.
First, what MCP actually is
Skip this section if you already know. If you don’t, it takes ninety seconds and it’s worth understanding, because it explains what has genuinely changed in the last year.
Start with an API. An API is a piece of software’s front desk. It’s a published list of requests the software agrees to accept from other software, in a format it agrees to understand. When your accounting app pulls transactions from your bank, it isn’t reading the bank’s website like a person would — it’s walking up to the bank’s front desk and filing a specific request. APIs are how nearly everything on the internet talks to everything else.
MCP — the Model Context Protocol — is a standard that gives an AI assistant its own access to those front desks. Before MCP, an AI could only ever advise you. You’d describe your problem, it would describe a solution, and then you did the work: copy, paste, adapt, test, fix what it got wrong. The AI never touched anything real.
With MCP, it does. Concretely: inside the AI, I type “make the button on the contact page green.” Over in FlutterFlow — the tool we build apps in — the button turns green.
That’s the whole idea. The AI stopped being an adviser and became something that can pick up the instruments.
Why we call it a scalpel
We started testing FlutterFlow’s MCP the day Abel at FlutterFlow launched it, on our own test apps rather than on client work. The tests ran from the absurdly ambitious to the trivially small, and the results told a clear story.
At one end: build me a whole gym app. The output was garbage. Not “needs polish” garbage — genuinely not worth the time it took to read.
At the other end: change these colours. It did that fine. It also wasn’t worth doing, because we can change colours faster ourselves by clicking on them.
So the useful zone isn’t “big tasks” and it isn’t “small tasks.” It’s a specific shape of task: narrow in scope, but deep in technical difficulty. A home feed sorting algorithm. A gnarly filter. A chain of conditional logic with five interacting rules. Problems where the surface area is one small part of the app, but the thinking underneath is genuinely hard.
That is a scalpel’s job. Small incision, precise, into something that needs real skill. The industry keeps selling AI as a chainsaw — point it at the forest and stand back. In our experience the chainsaw setting produces a mess you then pay someone to clean up.
Here is the part nobody puts in the marketing
MCP frequently makes our work slower.
Sometimes it takes longer than not using it at all. Sometimes it produces worse work than we would have. Sometimes it fails our QA outright and we throw the whole attempt away. That is not a knock on the technology — it’s the nature of a specialised instrument. You don’t reach for a scalpel to hang a picture.
The pattern we’ve settled on: MCP is like a laser. It is superb at the exact thing you point it at, and it becomes shallow and superficial the moment you ask it to comprehend the whole project. A FlutterFlow project holds an enormous amount of information, and asking any AI to hold all of it at once produces confident, plausible, wrong answers.
Worth noting where that limit isn’t: MCP rebuilt this website in a day or two. A marketing site is a far smaller, far more forgiving system than a production mobile app. Don’t let anyone quote website speed at you as though it predicts app speed.
MCP needs leadership and discretion. Sometimes you use a hammer, sometimes a screwdriver.
For app work specifically, MCP still very much needs a CTO — someone who already knows what correct looks like, who can tell the difference between a real solution and a convincing one, and who decides when not to cut. It is a new tool in the toolbox. It is not a tool that creates tools, and it is not a replacement for people who know what they’re doing.
How we keep it safe
Because it can touch real things, the discipline matters more than it used to. Our rules are unglamorous and non-negotiable:
- Back up the project before MCP goes anywhere near it. Every time.
- Save as we go, inside the project, so every step is individually revertible — not just the whole session.
- Point it at one narrow thing. Scope discipline is most of the skill.
- A human reviews the result against QA before it goes anywhere near a user. If it fails, we throw it out rather than patch it.
Those rules aren’t hypothetical. Here is the incident that wrote them.
The same feature I opened this post with — the feed algorithm, on a bucket-list app — is also where MCP did real damage. When it wrote the finished logic back into the project, it mangled the file: the function’s own definition got recursively nested into the slot where the code should live, and FlutterFlow could no longer parse it at all. Then the obvious fix made things worse. Pushing a revert through the same channel simply wrote the same corruption one level deeper.
Recovery was manual: paste the Dart into the FlutterFlow editor by hand, compile, save, re-sync to confirm it was clean. We have since watched the same failure twice more on other projects, so it isn’t a one-off.
Which produced the rule we actually operate by, and the sharpest way I can put any of this: read with the MCP, cut by hand. Let it diagnose freely. Make the incision yourself, in the real tool, on anything that matters.
None of that is exciting. All of it is why we can use a powerful instrument on live client work without gambling with someone’s product.
Who this actually changes things for
The surprise, for us, wasn’t the effect on our engineers. Our code-native people like MCP, but they treat it as one more tool among many — useful, unremarkable.
The real shift was for our non-coding team members. People who are deep experts in design, product, and QA can now accomplish things that previously required an engineer’s time. That’s a genuine expansion of what a small team can do, and it’s the thing I’d point to if you asked me what MCP changed about InfiniteUp.
It feels like a new teammate. And like any teammate, the point isn’t that they replace anyone — it’s that the team is more than the sum of its parts. Technology should empower small expert teams. We’d rather be experts in our domain, equipped by our tools, than slaves to them — and we keep evolving the set as the frontier moves, so that the frontier moving is good news for us instead of a threat.
If you’re paying someone to build your app
You don’t need to understand MCP. You do need to know whether the team you’re hiring has judgment about it, because the difference shows up in what you receive. So ask them:
- Where do you use AI, and where do you refuse to? “Everywhere” is a bad answer. So is “nowhere.”
- What’s your rollback plan when an AI-assisted change goes wrong? If there isn’t one, that’s your answer.
- Who reviews the output, and against what standard? There should be a named human and an actual QA process.
- Show me something AI got wrong on a real project. Anyone doing this seriously has a list. A team with no failures either isn’t using these tools or isn’t telling you the truth.
The reason we’re comfortable publishing the unflattering parts is that the unflattering parts are the expertise. Knowing that the chainsaw setting produces garbage, that colours aren’t worth automating, and that a two-week logic knot is exactly the right target — that knowledge came from doing it on real work and getting it wrong first.
A scalpel in the right hands is a remarkable thing. In the wrong hands it’s just a sharp object.
A note on process: this post was drafted with Claude, which also carried out the website work it describes — through MCP, on the live site. The judgment calls, and the mistakes, are ours.