DEV Community: Abdelmoula Bilel

Low-Code or Full-Code: Where Should a Beginner Start?

Abdelmoula Bilel — Sat, 07 Nov 2026 14:25:10 +0000

I already wrote about low-code vs full-code in production. This post is about something else: which one to start with when you’re learning. The answer depends on your background.

If you already know some code, go full-code

If you studied programming, coded a bit at school or tried it before, go straight to full-code. Same if you want to learn the details, like how things work under the hood, why code is written a certain way and how to structure a real project.

You already have the basics, so a visual tool would mostly slow you down. Pick something like React and start building.

If you’ve never touched code, start with low-code

Opening a code editor for the first time can be a lot: files everywhere, syntax errors, tools to install and words you don’t know yet. Many people give up at that point.

Low-code removes most of that. You see a lot less code, but you still work with the same concepts:

Concepts you learn in low-code

Variables: a named box holding a value, that you can click and check
Loops: a “for each” block around the steps it repeats
Conditions: an if/else block with two paths
Fetching data: a query step, with its result right in front of you
Returning data: the response your API sends back, field by field
API calls: a request to another service, with what goes in and what comes out

Take an API. In low-code you see the endpoint, the inputs it takes, the steps it runs and what it returns. The first time, that’s easier to understand than reading it in a file. A lot of people learn better by seeing things, and low-code works well for that.

When to switch to full-code

Once those concepts feel normal, moving to code is much easier, because you already understand most of what the code does.

Signs you’re ready:

you know what a variable, a loop and a condition do
you know what an API is and how data comes back
you can fix a broken workflow on your own
you want more control than the tool gives you
you’re curious how it works underneath

AI tools make that switch easier too, as long as you understand what the AI writes. (More on that in low-code or vibe coding.)

In short

If you studied code or want to learn the details, go full-code.

If you’ve never coded, start with low-code, learn the concepts, then move to code.

In both cases the goal is to understand what you’re building. (If you’re choosing a frontend tool, see WeWeb vs React.)

I first posted this on my blog, where it’s also in French and Arabic. What did you start with, and would you pick the same again?

WeWeb or React: Which One Should You Start With?

Abdelmoula Bilel — Sat, 07 Nov 2026 14:25:05 +0000

I get this question a lot, so I’ll answer it from what I actually did.

On the recruitment ATS/CRM I worked on, the frontend was first built in WeWeb. Later we rebuilt the whole frontend in React 19 + TypeScript, and most of that work was done with Claude Code. So I’ve used both on the same product, with real users.

My answer is simple: if you’ve never coded before, start with WeWeb. If you already have some notions of code, start with React.

Why WeWeb if you’ve never coded

WeWeb is easy to pick up. You put elements on a page, connect them to your data, and add workflows that run when someone clicks a button or submits a form.

What I like is that it teaches you how a frontend works while you build:

What you pick up in WeWeb:

how a page fetches data from an API
where that data is kept while the page is open
workflows: when this happens, do this, then that
variables and conditions
what to do when a request fails

You do the same things in React later. In WeWeb you just do them visually first.

It’s also a good option if you don’t want to vibe-code everything with AI. You build each part yourself, so you understand what you made. (I wrote more about that in low-code or vibe coding.)

Why React is easier to get into now

A few years ago React was harder to start with. You had to set up the project, learn the tooling and write everything by hand before anything worked.

With Claude Code that’s different. You describe the page, it writes the components, and you review and fix what it wrote. You can build a lot more in a lot less time.

That’s how we did our migration. We added React pages one by one while the WeWeb app was still running, until React was the whole frontend. We used TanStack Query, React Hook Form, Zod and React Router.

WeWeb app in production
React pages added one by one
Both running during the migration
React becomes the whole frontend

How we moved from WeWeb to React

For a big app that keeps growing, I’d pick React today because you have full control over the code. (More on my React work.)

React is harder to debug

In WeWeb, when something breaks, you open the workflow and check each step. You can see what the API returned and which variable is empty.

In React the problem can be in a component, a hook, the state, the cache, a request or a type. You check the console and the network tab, and follow the data through several files.

If AI wrote a big part of the code, a beginner will have a hard time here, because you’re debugging code you didn’t write and don’t fully understand yet. That’s where I see most people get stuck.

WeWeb

you see each workflow step
you see what the API returned
fewer places for a bug to hide
less freedom when the app gets big

React

full control over the code
AI writes it much faster
bugs can be spread across files
you need to read code to fix it

Which one to start with

Start with WeWeb if

you’ve never written code
you want to see how data and workflows work
you want to build something real soon
you don’t want AI doing everything for you

Start with React if

you already know some code, even a little
you studied programming or tried it before
you want to learn the details
you plan to build bigger apps

Starting with WeWeb doesn’t lock you in. When you move to React later, you’ll already know how data is fetched, what state is and how a workflow runs, so it’s mostly about learning to write it as code.

If you already know some code, I wouldn’t spend months in a visual tool. Go to React, use AI to go faster, and read what it writes.

For a large frontend I’d use React today. But WeWeb got us far quickly, and I’d still recommend it to someone who has never coded. (For the bigger picture, see low-code vs full-code.)

I first posted this on my blog, where it’s also in French and Arabic. What did you start with, and would you pick the same again?

Is Xano Good Enough for Production? What I Learned Using It

Abdelmoula Bilel — Sat, 07 Nov 2026 14:25:00 +0000

Yes. I used Xano as the backend of a recruitment ATS/CRM in production for about two years. The platform had around 150K person records, roughly 35K candidates, thousands of jobs and projects, and dozens of people using it every day. Xano handled the APIs, permissions, background jobs, AI workflows and most of the business logic.

So this comes from real use, not a side project. But there are a few things you should know before you rely on it.

What Xano gives you

You get pretty much everything a production backend needs:

What’s included

Database: tables and relations, add or remove fields
Indexes: add them on the columns you filter on
APIs: REST endpoints with auth and permissions
Request history: what each call received, returned and how long it took
Background tasks: scheduled jobs and work outside the request
External APIs: call OpenAI, Google, email tools and others

On that project Xano called OpenAI for CV extraction and candidate matching, Google Vision for OCR, Google Places for locations and Brevo for emails. If a service has an API, you can call it from Xano.

You can see what your backend is doing

This is the main reason I recommend it to people who aren’t very technical yet.

Your data is right there in tables, and you can see how the tables are related. When you open an API you see every step it runs, in order, and the request history shows what came in, what went out and how long it took.

In a regular backend most of this lives in files, logs and the terminal. Having it on screen makes it a lot easier to understand what’s going on, and to find the problem when something is wrong.

Using it with Claude Code

Xano now has XanoScript, which lets you write backend logic as code, and an MCP server you can connect to Claude Code.

I’ve used the Xano MCP with Claude Code myself. You can build a full backend in a few hours, or refactor a whole app in minutes. And if you can’t read walls of code, you can open Xano and see visually what Claude did.

I like that combination a lot: you get the speed of AI, and you can still check the backend yourself.

What you still need to know

Xano makes building the backend easier, but the usual backend problems are still there.

At one point some APIs on that app took 5–40+ seconds under load. That wasn’t Xano’s fault. We had missing indexes, heavy joins, too many database calls in one request, and work running inside the request that should have been in the background.

We fixed it with PostgreSQL indexes (including GIN and geospatial ones), better queries, fewer repeated calls, pagination and background tasks. I wrote the details in what slowed down our Xano/PostgreSQL backend.

What I’d check before going live on Xano:

indexes on the columns you filter and sort by
pagination on every list endpoint
no database calls inside big loops
heavy work (AI, emails, imports) in background tasks
permissions on every endpoint, not only in the frontend

You’d have to do the same things in Node.js or any other backend.

Is it good enough?

For most business apps, like CRMs, dashboards, internal tools and SaaS products, yes. Xano is more than enough. And if you’re not very technical, it helps a lot that you can see what’s going on.

I wouldn’t use it for every project. Some fit a full-code backend better, and I explain when in low-code vs full-code. Whether Xano can run in production isn’t really the question anymore. What matters more is that you understand what you’re building on it. (More on my Xano work.)

I first posted this on my blog, where it’s also in French and Arabic. What did you start with, and would you pick the same again?

Low-Code or Vibe Coding: What Should You Start With?

Abdelmoula Bilel — Sat, 07 Nov 2026 14:24:55 +0000

By vibe coding I mean describing what you want to an AI, accepting the code it gives you and moving on without really reading it. If it runs, you ship it.

It does work. You can have an app running in an afternoon.

But if you’re starting out and you want to learn how to build things, I’d start with low-code, and move to AI coding once you understand how a good app is put together.

Why I wouldn’t start with vibe coding

You don’t learn much from it. The AI decides the structure, how data is fetched, where it’s stored and who can access it. You only see the end result.

That’s okay until something breaks, gets slow or has a security hole. Then you’re reading hundreds of lines you didn’t write, asking the same AI to fix its own code, and hoping it works this time.

What low-code teaches you

In low-code you build visually, but you’re still the one building it, and every part is in front of you.

You see how the app is structured, where the data is and how it gets to the page. You also learn how data should be fetched, not only how it happens to be fetched. When something goes wrong, you open it, check each step and fix it.

What you end up understanding

Structure: how an app splits into pages, APIs and data
Data: tables, relations and where things are stored
Fetching: how a page gets its data, and how it should
Debugging: open a step and see what went wrong
Speed: why some requests are slow
Security: who can see what, and where to check it

My own path was different: I studied computer science and learned to code first. But Xano and WeWeb were a good balance for me. I could still write logic when I needed to, and I could see how the backend and frontend fit together, how an API runs step by step and why something was slow.

When to move to AI coding

Once you know how to start a project, how to structure it and how to make it fast and secure, AI coding becomes really useful.

At that point you can read what the AI writes. You notice when it fetches more data than it needs, or when an endpoint has no permission check, and you can tell it to do it differently because you know why.

That’s how I use Claude Code now. It writes a lot of my code, but I review it, because I know what it should look like.

Build with low-code
Understand data, APIs and structure
Learn what fast and secure look like
Use AI to write code faster
Review everything it writes

The order I’d recommend

Which one to choose

Choose low-code if

you want to learn how apps work
you want to understand what you build
you want to become a developer

Choose vibe coding if

you just need it done
it’s a quick prototype or a personal tool
you don’t care how it works inside

If you want to learn, start with low-code. If you only want results, vibe coding is fine. If you want both, do them in that order.

For picking a tool, I compare the frontend side in WeWeb vs React and the backend side in is Xano good enough for production.

I first posted this on my blog, where it’s also in French and Arabic. What did you start with, and would you pick the same again?

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

Abdelmoula Bilel — Sat, 24 Oct 2026 19:03:19 +0000

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.

Read the full version on my portfolio →