Himanshu Sharma has been building no-code apps for seven years. What started as a blog where he shared what he was building, turned into client requests, which turned into a full-time agency.
Today, NocodeAssistant is a four-person team that builds internal tools, SaaS products, and MVPs for SMBs and early-stage startups: companies with 10 to 30 employees that are still managing operations through spreadsheets or copy-pasting data between platforms.
For the first five years, Bubble was their only tool of choice. Then they decided to explore alternatives.
Three things pushed the agency to question their Bubble-first approach.
First, pricing. Bubble's model tied costs to workflow usage, and at the start of a project, it was almost impossible to predict how many workflow units you would need.
Every new feature added workflows, and every workflow added cost. That made pricing harder to predict and explain to clients.
“With WeWeb, it’s easier to estimate costs upfront and explain them to clients,” Himanshu says.
Second, clients started asking about vendor lock-in. With Bubble, there's no way to export your code. If a client outgrows the platform or wants to bring development in-house, they're stuck.
"It wasn't a deal-breaker, but it was something that we were being asked about,” Himanshu notes. “With WeWeb, we’re able to export the code, which removes that concern.”
Third was backend flexibility. Bubble is designed as an all-in-one platform, which works well until you want to bring your own backend.
Himanshu wanted to pair tools like Xano and Supabase with his frontend.
“Bubble works great if you want everything in one place,” Himanshu says. “But once you decide to bring your own backend, WeWeb integrates more naturally with Xano and Supabase.”
At that point, the team decided to make the switch. But how do you migrate live client apps without disruption?
They began by migrating two client applications already in production.
The team first rebuilt the backend in Xano rather than trying to port it directly. They then used Bubble’s APIs to export and transfer the database, with some reformatting along the way.
There were no major technical blockers, just careful data validation and linkage checks.
The migration was also an opportunity to fix what wasn't optimal the first time.
"Some things are easier to do in Xano compared to the Bubble patterns, so we did some optimizations," Himanshu explains.
Instead of rebuilding the entire frontend at once, they migrated one module at a time.
"We first moved the modules which were not regularly used," Himanshu describes. "And the ones that we use very often, and are also critical, were migrated last."
1️⃣ Start with the quiet modules. Simple, self-contained pages like profile settings or simple admin pages. These went live in WeWeb while the core application still ran in Bubble. Users navigated between platforms without knowing it.
2️⃣ Work toward the critical, connected modules. Integrations, user management, and critical company data moved last. By then, the team knew WeWeb well.
3️⃣ Run both platforms simultaneously. Users clicking certain links in Bubble would be routed to WeWeb for the migrated modules.
4️⃣ Cut the Bubble frontend loose. Once every module ran in WeWeb, they dropped the link.
The backend took about a month. The frontend took two.
During the overlap period, authentication had to work on both platforms simultaneously, pointing to the same database. That coordination added time but kept the product live throughout.
Total migration time: three months.
Most of Himanshu’s clients are non-technical and don’t see the stack behind an app, but they did notice that pages loaded faster.
"Most of our clients don’t understand what happens under the hood," Himanshu says. "But there were changes with regards to page load speed. It improved. And the pricing surprises stopped."
The shift changed how the team builds and collaborates.
Bubble: requires workarounds. It works, but it’s not always smooth.
WeWeb: native if / while loops. Clean and predictable.
Bubble: used mostly for edge cases.
WeWeb: available throughout the app, and enables more efficient execution for complex logic.
Bubble: styling is workable, but doesn’t follow traditional CSS conventions.
WeWeb: classes and subclasses behave like standard CSS, giving developers more control and structure.
Bubble: responsive design often relies on conditional logic.
WeWeb: switch to a breakpoint and design directly. Conventional and fast.
Bubble: page-scoped states with limitations.
WeWeb: flexible variable scoping, including global, page-level, and element-level variables.
“The learning curve is real, but so is the payoff,” says Himanshu.
When a 4-person team juggles 4-5 active projects, clean separation of tasks matters.
With Bubble, frontend and backend development blur. It’s hard for one person to focus purely on the backend while another focuses purely on the frontend.
“With WeWeb, we can separate responsibilities more clearly,” Himanshu says. “One person can focus on the backend, and another can work on the frontend without stepping on each other’s work.”
Here are Himanshu’s tips for anyone considering migration.
WeWeb is different from Bubble, and it requires a different mindset.
“Bubble is more self-contained,” Himanshu says. “WeWeb follows standard web development patterns, so the skills you learn are more transferable.”
Don't start the migration as your first WeWeb project. Start with something small, like a simple internal tool, where mistakes don’t cost much.
"It's better to do small projects before taking on a migration," Himanshu advises. “If you’ve been building only in Bubble for a while, you get used to certain workarounds.”
If Himanshu could do it again:
"I would spend more time with WeWeb and build a couple of minor projects just to see and understand how WeWeb works, because there is a learning curve."
Don't just copy Bubble architecture into WeWeb. Rebuild thoughtfully.
"Some things are easier to do in Xano compared to Bubble patterns," Himanshu notes. “Migration is the perfect time to fix old technical debt.”
And don’t forget to start with the simple, standalone pages. Save the complex, interconnected features for when you're confident with the platform.
Today, NocodeAssistant builds all new client projects on WeWeb, pairing it with Xano or Supabase depending on the project. Xano is typically used for early-stage MVPs because it’s faster to set up, while Supabase is chosen when clients want more control and have the technical resources to manage the backend.
The stack gives them flexibility on the backend, predictable pricing on the frontend, and the option to export source code if clients ever need it.
Himanshu still has one legacy client on Bubble, but all new work is on WeWeb.
Meanwhile, the blog that started the agency is still running.
“I’ve had a post about migrating from Bubble to WeWeb sitting in my backlog for a while now. Maybe I’ll finally write it soon,” he concluded.
