I Use Xano, React and Full-Code. I Don’t Think You Have to Pick a Side

Xano is one tool in my stack, not the whole stack

I genuinely like Xano.

Not because I’m trying to avoid backend code. It’s just a productive tool.

I’ve used it for database schemas, relationships, REST APIs, permissions, authentication, triggers, background tasks, scheduled jobs, integrations and a lot of business logic. (More on that on my Xano work page.)

And once the application gets more serious, you still need to understand what’s actually happening underneath.

At one point, some APIs on a production system I worked on could reach 5–40+ seconds under load.

There was no magic button to fix that. We had to look at the actual backend.

Some queries were expensive. Some flows were making too many database calls. Some joins were heavier than they needed to be. Some triggers were doing work that shouldn’t have happened inside the request.

We added PostgreSQL indexes, including GIN and geospatial indexes, improved queries, reduced repeated calls, added pagination and moved heavier work into background tasks. I wrote up the details in what slowed down our Xano/PostgreSQL backend.

Solving it still required understanding the database and the way the application behaved.

That wasn’t really a low-code problem. It was a backend problem.

It can also go further than people think

The main product I worked on wasn’t a tiny MVP.

It was a recruitment ATS and CRM with around 150K person records, roughly 35K candidates, thousands of jobs and projects and dozens of internal users.

There were applications, activities, companies, opportunities, permissions, reports, migrations, AI workflows, candidate matching and background processing. A lot was happening inside that system. (The full story is in the Talent Match case study.)

And Xano was still useful.

That doesn’t mean I would use it for literally everything. I wouldn’t.

But I also don’t think a tool becomes unserious just because part of the development experience is visual. If it solves the problem well, scales to what you need and your team can maintain it, then it’s doing its job.

We made a different decision on the frontend

The same product originally had its frontend in WeWeb. And WeWeb also helped us move fast.

But over time, the application became much more complex: a lot of forms, filters, dashboards, Kanbans, permissions, interconnected workflows and state to manage.

Eventually, we rebuilt the entire production frontend in React 19 + TypeScript. Gradually, not in one jump:

For that stage of the product, I think it was the right move.

We got much more direct control over the codebase. We could standardize things properly around TanStack Query, React Hook Form, Zod, React Router, reusable components and TypeScript. The frontend became something developers could reason about directly as a codebase. (More on my React work.)

Personally, for a large frontend that I expect to keep growing, that’s the direction I would lean toward now.

But I still don’t look back at WeWeb and think using it was a mistake. It got us somewhere quickly. Then the needs changed. So the stack changed too.

That’s normal.

AI makes switching much easier now

This is the part I find the most interesting.

Moving from low-code to full-code is way easier today than it was a few years ago.

During the React migration, I used Claude Code a lot. It helped with repetitive implementation, refactoring, finding patterns across the codebase and turning existing behavior into React components faster. It definitely reduced a lot of mechanical work.

I think the same thing applies to backend work now. If I eventually need to move part of a system into Node.js, AI can help with scaffolding, types, repetitive endpoints, tests, refactors and a lot of the boring parts.

But there’s a big difference between writing code faster and understanding a system.

AI doesn’t automatically know why a weird permission rule exists. It doesn’t know which edge case caused a production bug six months ago. It doesn’t know which behavior users depend on even though nobody documented it.

That still comes from understanding the product. (I write about the AI side of my work on the AI integration page.)

AI makes migration cheaper. It doesn’t make the decision automatic.

And easier to rewrite doesn’t mean worth rewriting

This is probably the biggest thing I learned from working with both.

It’s very easy now to look at an existing system and think: “We could rebuild this.”

And yeah, maybe you could. But should you?

$ ./should-we-rewrite
  users happy?          yes
  performance fine?     yes
  team can maintain it? yes
  real reason?          "feels cleaner"
→ verdict: don’t rewrite (yet)

If the current system works, users are happy, performance is fine and your team can maintain it, rewriting it just because full-code feels cleaner can easily become wasted work.

You can spend months rebuilding things users already had. You can introduce new bugs. You can miss old business rules. You can end up with a nicer architecture and almost no extra value for the product.

I’d rather migrate because I have a real reason. Not because I want the stack to look cooler.

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: custom services, specific libraries, deeper testing, more control over deployment or runtime behavior, or an architecture that simply fits a traditional backend better. Then something like Node.js makes sense.

And I want to work more with that kind of stack too. React + Node.js + PostgreSQL is something I can absolutely see myself building with.

But that doesn’t mean I need to stop using Xano. If I can ship a backend faster with Xano and the project fits it well, I’d still seriously consider it.

Both things can be true.

Xano is one tool in my stack, not the whole stack.

Hybrid stacks make a lot of sense to me

I actually think this is where things get more interesting. You don’t have to make one decision for the entire product.

That seems completely normal to me.

Use the higher-level tool where it saves you time. Use full-code where you need control. And don’t rewrite parts that already work just because you can. (On the database side, that’s the kind of work I describe on my PostgreSQL performance page.)

So when would I actually move away from low-code?

Probably when I start spending more time fighting the platform than benefiting from it.

Then yeah, I’d move. But I’d want that decision to come from the product, not from ego.

Where I stand now

I’m a full-stack developer. I like React and TypeScript. I like working directly with PostgreSQL and APIs. I’ll most likely use more Node.js and other full-code backend technologies.

And I still like Xano. I don’t think any of those things conflict.

Xano is one tool in my stack. Full-code gives me another level of control when I need it. AI makes moving between those levels easier than ever.

So I don’t really ask “Is low-code better than full-code?” I’d rather ask: “What should I actually use for this part of the product?”

Sometimes the answer will be Xano. Sometimes Node.js. Sometimes React. Sometimes WeWeb. Sometimes a mix of all of them.

As long as I understand what I’m building and why I’m choosing the tool, that matters much more to me than picking a side.