Read the full version on my portfolio →
I Use Xano, React and Full-Code. I Don’t Think You Have to Pick a Side
I’ve worked with both low-code and full-code tools in production, and honestly, I think people make the argument way more dramatic than it needs to be.
Use React and people call you a React developer.
Use Xano or WeWeb and suddenly you’re a low-code developer.
Then the discussion becomes:
Which side are you on?
I’m not really on a side.
I’m a full-stack developer.
A big part of my backend work over the last couple of years has been with Xano. On the frontend, I’ve worked with WeWeb, and later helped rebuild a production app in React 19 + TypeScript.
And to me, these are just tools.
If Xano helps me build something properly and faster, I’ll use Xano.
If I need more control and a full-code backend makes more sense, I’ll use that.
That’s it.
Xano didn’t remove the engineering part
One thing I think people get wrong is assuming that using a higher-level tool means the hard parts disappear.
They don’t.
On one production system I worked on, some APIs could reach 5–40+ seconds under load.
That obviously wasn’t acceptable.
The fix wasn’t “stop using Xano”.
The fix was backend work:
- improving queries
- reducing repeated database calls
- adding PostgreSQL indexes
- fixing heavy triggers
- adding pagination
- moving some processing into background tasks
That wasn’t really a low-code problem.
It was a backend problem.
Low-code can go much further than people think
The main platform I worked on wasn’t a tiny MVP.
It was a recruitment ATS + CRM with around:
- 150K person records
- 35K candidates
- thousands of jobs and projects
- dozens of internal users
There were applications, CRM activities, permissions, AI workflows, candidate matching, background jobs, reporting, migrations and a lot more going on.
So no, I don’t think tools like Xano are only useful for toy projects.
Would I use it for every backend?
No.
But I also wouldn’t dismiss it just because it’s more visual.
We made a different choice on the frontend
On the frontend, we eventually moved from WeWeb to React + TypeScript.
And I think that was the right call for that stage of the product.
As the app grew, having more direct control over the codebase started mattering more.
That doesn’t mean WeWeb was a mistake.
It just means the product changed.
So the stack changed too.
That feels completely normal to me.
AI makes switching easier, but not automatic
This is probably the most interesting part now.
With tools like Claude Code, moving from low-code to full-code is easier than it used to be.
There’s a lot less repetitive work.
But easier to rewrite doesn’t automatically mean worth rewriting.
That’s the important part.
You still need to understand:
- the business rules
- the edge cases
- the weird old behavior users depend on
- what actually needs to change
AI can help write the replacement.
It doesn’t decide whether replacing it is a good idea.
I’ll probably use more Node.js too
I don’t see my future as “Xano forever”.
There are definitely projects where I’d rather own the backend directly.
A stack like React + Node.js + PostgreSQL makes a lot of sense to me, and it’s something I absolutely want to build more with.
But that doesn’t mean I need to reject Xano.
I think both can be true:
- sometimes a higher-level tool is the smart choice
- sometimes full-code is the smart choice
That’s why I don’t think you need to pick a side
For me, the real question isn’t:
Is low-code better than full-code?
It’s more:
What makes sense for this product right now?
Sometimes that answer is Xano.
Sometimes it’s Node.js.
Sometimes React.
Sometimes a mix.
And honestly, I think that’s a much healthier way to think about it.
Top comments (0)