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 (3)
Your line that it was a backend problem, not a low-code problem, matches what I have seen in my own work. I have watched a list endpoint crawl for the same reasons you list: a missing index here, repeated database calls there, and no pagination, so one page tried to carry the whole table. Changing the tool would not have fixed any of that; fixing the queries would.
The move from WeWeb to React is the part I am most curious about. Was there one specific moment when direct control over the code became unavoidable, like a custom interaction or a state problem the visual builder could not express, or was it a slow accumulation of small frictions?
yes first point was 100% a backend problem,
and to answer your second point, the visual builder is fine but you can feel slight slowness on it when pages load or when an edit modal opens or small things so that in React were so much better and you don't feel that lag but weweb is still very useable.
2nd point is that now react can be used by claude code so any changes would be done quicker, it have more context than any dev so knows for example changes that should be done across the platform you built and it can test it self.
for big projects i would choose react as a FE everyday, small projects weweb is still very nice especially for someone just starting developement.
fair split. keep weweb where speed matters most, react where the project outgrows it.