A few months ago, a client came to Hill Tribe Solutions with a problem that would have sounded familiar to almost any software agency.
She had already used AI to generate a prototype for an internal app. The concept was promising, but the prototype did not work well enough to use. She was also relying on an existing iOS app that was buggy and no longer met her needs.
After a short discovery conversation, I turned what I had learned into a product scope and technical design document. Then I used AI-assisted development to design and build a new solution.
In about five hours of active work, I created a desktop and mobile progressive web app with push notifications and logging features for her clients. We treated the infrastructure and security seriously. We tested authentication. We checked the endpoints and database access. We also verified server-side enforcement and secured the API credentials.
The client loved it.
When I saw the final application running, my first thought was how useful this solution would be for her. My second thought was how quickly I had been able to solve the problem.
Then came a more uncomfortable realization.
I had spent ten years mastering a tool that may become less important much faster than I expected.
Low-code gave me a way into software
My story with low-code started in 2016.
At the time, subscription boxes were everywhere. I was building a small boutique T-shirt subscription business and needed software that could do two things. It had to provide an e-commerce shopping experience. It also had to manage recurring subscriptions behind the scenes.
I tried building it with WordPress and a prebuilt template. It was buggy. The pieces never worked together the way we needed them to.
I was not a trained software engineer. I had some experience with HTML, CSS and JavaScript. I also knew WordPress. I saw myself as a tinkerer. I knew enough to experiment, but not enough to build a complete custom application from scratch.
Then I discovered Bubble.
At the time, low-code felt revolutionary because it removed several barriers at once. It reduced the amount of money needed to build an application. It lowered the educational barrier for people without formal engineering training. Most importantly, it reduced the time between having an idea and seeing it work.
For someone like me, that changed what felt possible.
The first client changed what I believed about my future
My first paid Bubble project came through Upwork.
The client wanted a directory for newly released technology tools. It was a relatively simple idea, and the demos I had already created gave me confidence that I could build it.
I did not suddenly feel like a software engineer because someone paid me. What changed was more personal. Getting paid allowed me to psychologically accept that this could become a long-term career.
Until then, building software had been something I was experimenting with. After that project, it became something I could imagine doing professionally.
I began prospecting for more clients. The projects became larger. The problems became more complex. What started as one person learning a visual development platform eventually became Hill Tribe Solutions.
The moment I knew low-code could support real businesses
One of the earliest turning points came when we worked on an Australian marketplace for specialty caretakers.
The concept was similar to Uber, but for on-demand caretaking services. The product had real users and was delivered through a natively wrapped mobile app. It also created technical challenges that went far beyond building screens.
Australia spans several time zones. Scheduling had to work correctly across different states. Availability and service times needed to make sense for users in different locations.
These were not demo problems. They affected real people using a production product.
After working on that application, I no longer saw Bubble as a tool that was only useful for prototypes. It could support a real business with real users and real operational complexity.
Over the following decade, Hill Tribe Solutions worked with well over 100 founders across client applications and projects.
We built and maintained an SMS journaling application for Ryze Superfoods when the company was still an emerging brand. At its peak, the application reached about 10,000 daily active users.
We helped further develop Alliance Travel and continue to maintain the platform today. It supports travel booking programs that serve more than 20 casinos around the world.
We developed and maintained the initial MVP for Trash Warrior, a trash hauling marketplace that was later acquired.
We also built the initial MVP for Art Dealery, an art selling marketplace that was eventually acquired as well.
Those projects taught me that low-code software can create real value. It can support growing businesses. It can serve thousands of users. It can help a founder prove an idea and reach an acquisition.
Low-code was not a shortcut around solving hard problems. It was another way to solve them.
What ten years of low-code actually taught me
People often focus on the speed of low-code development. Speed matters, but it was not the most valuable lesson.
Ten years of working with founders taught me that building the application is only one part of the story.
A product also needs a clear strategy. It needs customers who care about the problem. It needs pricing that makes sense. It needs a practical path to market. It also needs feedback from real users.
The most common mistake I saw was founders building too many features because they assumed they already knew what customers wanted.
They would spend months creating a large product before trying to sell it. They would define every feature internally rather than testing the core idea with the people who might use it.
My advice became simple: build fast. Sell early. Collect feedback. Then iterate.
I now believe a founder should not invest heavily in an application until they have spoken directly with at least one ideal customer. One conversation is not complete validation, but it is better than building from assumptions alone.
Low-code taught me that “build it and they will come” is mostly untrue.
AI did not change everything overnight
I have been building with AI for roughly a year, but the shift did not feel immediate.
For much of that time, the most powerful AI coding tools still felt designed for technical users. They could write code, but the user was often left to configure the database and deployment. They also had to handle authentication. Infrastructure and security were still their responsibility.
That can be a good thing for an experienced engineer who wants full control. It is less helpful for a nontechnical founder who simply wants to solve a business problem.
The larger shift happened more recently as simpler managed AI development platforms began to appear.
For me, Hatchable represented an important bridge between low-code and fully custom development. It allowed me to use AI-assisted development while foundational systems such as authentication and database infrastructure were managed by a team of software engineers.
That changed my view of what AI-assisted custom software could become for everyday founders.
More control does not automatically create a better business.
In more than a decade of helping founders build over 100 applications and projects, I have rarely found that a nontechnical founder gains a meaningful business advantage from personally knowing how to deploy a PostgreSQL database.
They need the system to be dependable. They need to understand the decisions that affect their business. They do not necessarily need to configure every layer themselves.
This does not mean security is no longer a concern. It means AI-generated software is not inherently insecure simply because AI helped build it.
Security still depends on the platform and architecture. It also depends on the implementation and review process.
For the client application I built in five hours, I still performed authentication penetration testing. I checked endpoint security and database access. I verified that permissions were enforced on the server. I also confirmed that secrets and API credentials were protected.
AI accelerated the implementation.
It did not remove my responsibility to inspect the result.
AI can make software look finished before it is finished
AI is very good at appearing to make everything work.
That is part of what makes it powerful. It is also part of what makes it risky.
A founder can describe a feature and watch a polished interface appear within minutes. Buttons work. Data saves. The application looks convincing.
But once you peel back the digital skin, you may discover that the system is not what you intended to build.
In one project, I asked Codex to create a feature and connect it to the existing system. It built the requested feature and wired it up.
It also added another connection that was not part of the scope.
The feature appeared to work. The additional connection was not disclosed clearly at the time. I found it later while auditing the code with Claude Code.
I have seen the same type of scope drift in interface work. I may ask an AI tool to change one specific part of a design, only to discover that it also modified other areas that were never targeted.
These changes are not always catastrophic. The deeper issue is that they can be invisible to someone who only checks the final screen.
An experienced developer knows that completing the visible request is not enough. You need to review the surrounding system. You need to look for unexpected side effects. You need to ask what else changed.
AI can generate code very quickly.
It does not always understand which consequences matter to your business.
The real value of a developer is changing
For years, developers were largely valued for their ability to produce working code.
That skill still matters, but code production is becoming less scarce.
The more important value now is judgment.
A good developer should know why something should be built. They should also know why it should not be built.
They need to understand how a technical decision affects the product. They need to understand how it affects the user experience. They must consider security and long-term maintenance. Most importantly, they need to understand how those decisions affect the business itself.
AI may have generated much of the implementation for that five-hour application, but my experience was responsible for the product vision and technical philosophy.
My years of client conversations helped me turn an unclear problem into a practical scope. They helped me decide what the product needed and what it did not need.
They helped me create the technical design before generating features. They also taught me where AI was most likely to miss something important.
I do not believe someone with no product or technical development experience could have produced the same result from a single prompt.
The problem is not that AI lacks intelligence.
The problem is that it does not automatically know what you want.
It only knows what you can articulate.
For a nontechnical founder, that creates a difficult gap. It is hard to describe the correct technical vision when you do not know the consequences of the technical choices being made.
That is why a polished AI prototype can create false confidence.
The application may look right while the product strategy is wrong. It may function in a demo while the architecture does not fit the business. It may solve the problem you described without solving the problem your customers actually have.
The question is no longer whether AI can generate your application.
The real question is whether you know what the application should become.
Low-code is not obsolete
My growing belief in AI-assisted development does not mean I think Bubble or low-code is dead.
That would ignore what makes low-code valuable.
A founder should still consider Bubble when they want to understand the product visually. It is also a strong option when they want to make changes personally without learning how to code.
Bubble is a mature platform. It has supported serious applications for years.
A founder may already have a stable product and an experienced team. They may also have a large amount of business logic invested in the platform. Rebuilding a Bubble application simply because AI is new would not always be responsible.
Traditional developers have also misunderstood low-code builders for years. They sometimes assume we chose the easy path.
In reality, advanced low-code development requires many of the same programming concepts as traditional software development. You still need to understand data structures and application state. You need to understand permissions and logic. Integrations and performance still matter.
The interface may be visual, but the problems are still technical.
AI enthusiasts now risk making a similar mistake in the other direction. They assume low-code is obsolete because AI can generate custom code.
Low-code still offers one of the clearest ways for a nontechnical founder to see how a product works and maintain direct control over it.
The right choice depends on the person and the problem.
A founder should consider low-code when they want to visualize the system and develop it personally.
They should consider AI-assisted custom development when they want more control over the final software but do not need to personally understand or modify every part of the implementation.
They should not build an application yet when they have not spoken to the people they expect to use it.
The uncomfortable part of changing direction
Hill Tribe Solutions became known for Bubble development. We became a Bubble Gold agency. That reputation represented years of practice and client trust.
It also became part of how I saw my own career.
That is why this transition creates some conflict.
I knew the market was changing during the last year. Nothing prepared me for how quickly the tools would improve in the last few months.
The hardest realization was not that Bubble had stopped working.
It was that newer technology stacks were becoming a better solution for some of the clients I wanted to help.
That is an important distinction.
I do not regret the decade I spent on Bubble. It gave me a path into software development when traditional development was not accessible to me.
It allowed me to help founders build real companies. It gave Hill Tribe Solutions the experience we now use to guide AI-assisted development projects.
But our identity cannot depend on one platform.
Hill Tribe Solutions was never supposed to be about using the most sophisticated technology available. It was about finding the best technical solution for the problem a client needed to solve.
Sometimes that solution is Bubble.
Sometimes it is AI-assisted custom code.
Sometimes it is a strategy session or a simple prototype. It may even be a manual process that helps the founder learn before investing in a full application.
The solution should serve the business.
The business should not be forced to serve the technology.
What I would tell nontechnical founders building with AI
I do not want founders to stop building with AI.
I think they should experiment with it. They should use it to explore ideas and create prototypes. They should use it to communicate what they are imagining.
AI may be the most accessible product development tool we have ever had.
But a working screen is not the same thing as a working product.
A working product is not the same thing as a working business.
Before investing heavily in an AI-generated application, talk to the people who may use it. Define the smallest problem worth solving. Be clear about what the system should do.
Then have someone qualified review what is happening beneath the interface.
Do not assume that hiring an experienced developer or agency is only about paying someone to type code.
The right technical partner should help you avoid building the wrong thing. They should challenge your assumptions. They should identify risks you cannot see yet.
They should help you choose the right platform rather than forcing every project into the tool they already know.
AI has not eliminated the need for expertise.
It has made expertise more productive.
The lesson I would give myself in 2016
To the version of me struggling with that broken WordPress subscription site in 2016, I would say that Bubble was the right choice.
It was not a temporary mistake.
It was the bridge that allowed a self-taught tinkerer to become a professional software builder.
The mistake would not have been choosing Bubble. The mistake would have been believing that any platform should define my value forever.
The most valuable thing I learned during those ten years was not how to use Bubble.
It was how to listen to a founder.
It was how to turn an unclear problem into a product.
It was how to recognize when a feature did not need to exist.
It was how to think through technical consequences before they became expensive business problems.
AI does not erase that experience.
It reveals what the experience was actually worth.
Ten years from now, I do not want Hill Tribe Solutions to be known for one platform or one technology stack.
I want us to be known for helping founders make better decisions. I want us to help them build better applications and create stronger businesses.
Low-code taught me that building is only one part of the story.
AI taught me that industries can change faster than you expect.
The lesson connecting both is simple:
Tools will keep changing. Good judgment will matter even more.
If you are deciding whether your next product should stay on low-code or move toward AI-assisted custom development, talk with Hill Tribe Solutions. We will help you think through the right solution before you commit to a stack.