Issue #004 | Before You Build
It Still Writes Code
by Abe Challah |
Friday Code and PlugThis made me think less about how easy it has become to start building software, and more about how far these tools can actually take you before you get stuck.
A few weeks ago I built and deployed a to do app without opening a terminal.
That is not the impressive part anymore.
I was testing Friday Code for AppSumo, and what caught my attention was how far I could keep going after the first version appeared. That has always been the sticking point for me with no-code and, more recently, AI app builders.
Getting the first 70 or 80% was rarely the problem. I have built plenty of things over the years where the first version came together surprisingly quickly. Then you reach the awkward part. You need some logic the builder doesn’t quite support. An integration works differently than you expected. You need to change something deeper in the backend. Deployment becomes strange. You need access to code you don’t really own. Or you realize the workaround you created for one screen has now infected five other screens.
The demo works. The product doesn’t quite work yet.
That last 20%, sometimes the last 10%, is where no-code has traditionally asked you to make a choice. Accept the limitation, find another workaround, hire somebody who understands the platform really well, or eventually move the whole thing into a normal development environment.
AI app builders made the first 80% dramatically faster. What I’m becoming much more interested in now is what happens after that.
How far can I actually take this thing toward a final product?
Field Notes | A few useful finds
Friday Code & PlugThis AI
When I first took Friday Code for a deep dive, I used it to build a small to do app and a landing page. It didn’t get everything right on the first try, which was perfectly fine. I gave it follow-up instructions, corrected things I didn’t like and kept refining the project until I was much closer to what I had in mind.
After a few rounds I started getting a feel for how to guide it. I learned when I needed to explain the whole requirement and when a small instruction was enough. That experience was closer to directing development than pressing a button and hoping the generated app happened to be right.
This is where Friday gets interesting for me. It sits somewhere between the prompt-first builders and tools like Claude Code or Codex.
A product like Lovable can take someone from a description to an impressive first application very quickly. At the other end, a coding agent can work directly inside a real codebase and gives you almost unlimited flexibility if you know how to steer it.
But there is a fairly large gap between those two users.
I know a lot of founders, product people and capable non-developers who can describe an application in detail. They understand workflows. They understand users. They know what the screen should do, how the pieces should fit together and when the result is wrong. Some can even read enough code to understand roughly what is happening.
That doesn’t mean they want to manage a local development setup, Git repositories, package dependencies, hosting, deployment configuration and all the plumbing that developers have learned to deal with almost automatically.
Friday wraps a lot of that into the product.
You can start with a prompt, but you aren’t limited to a one-shot generation. You work through the project inside the desktop application, keep refining it through conversation, use local project storage and eventually export the codebase if you want to continue somewhere else. It also supports different AI models and OpenRouter, which I liked because it gives somebody who already has a preferred AI setup more control.
The templates are another part I really like.
Friday has a large collection covering different types of apps, websites, backends and tools. I don’t see those templates simply as designs. They are boilerplates. Instead of asking the AI to recreate the same basic foundation every time you have an idea, you can begin with something that already has much of the boring starting work in place and spend more of your time changing the parts that are actually specific to what you are building.
That becomes especially useful with AI because a template is no longer a fixed thing you spend hours manually customizing. It becomes a starting codebase the agent can understand and reshape around your requirements.
Friday has evolved quite a bit since my original test too. I ran into several launch-readiness problems in the early build, including compatibility and installation issues. I retested the launch version after the team worked through them and those concerns had been cleaned up. The partner later told me they had also improved the agents considerably based on the early feedback they were getting.
What I find interesting isn’t that Friday somehow removes developers from the equation forever. I don’t think any serious builder can promise that for every product.
It’s that the point where you may need a developer gets pushed further away.
You can get the idea working, iterate on it, use an existing boilerplate, deal with much of the project setup, deploy it and keep the underlying code available. For a capable non-developer, that is a very different ceiling from a visual builder where eventually you hit a wall and there is nowhere else to go.
PlugThis AI approaches the same last-mile problem from another direction.
It isn’t trying to build every kind of software. It builds Chrome extensions.
When I tested it, I described the extension I wanted in plain English and PlugThis generated a working Manifest V3 extension. I could install it, test it, continue changing it through chat, edit the files directly and download the complete source code when I was done. It can also handle APIs, backend pieces through Supabase, GitHub sync, version history and the things you need if the extension is supposed to become more than a little weekend experiment.
The interesting part is the specialization.
Chrome extensions have their own stack. There is a manifest, permissions, content scripts, background service workers, popup interfaces and a bunch of pieces that all have to fit together correctly before Chrome will even load your extension.
A general AI coding tool can obviously write JavaScript. That doesn’t automatically mean the result is packaged properly as a Chrome extension.
The founder basically confirmed this in his reply to my AppSumo review. Their whole bet is that extensions have enough of their own architecture that a focused builder can take responsibility for that layer instead of expecting the user to understand it first.
I like that direction because this is where AI builders can become much more useful than a generic prompt box.
I shouldn’t have to become a Chrome extension developer just to find out whether my Chrome extension idea is any good.
If the concept works and eventually becomes complicated enough that I need a developer, fine. I have the source code. I have Git. I have something real to hand over. But I can get a lot further before reaching that point.
And that, to me, is the bigger story behind both Friday and PlugThis.
They don’t eliminate code.
They move the point where I need to personally deal with it.
I have been using no-code tools for a long time, and this last 10 to 20% problem has always been sitting underneath the category.
The original promise was that people who couldn’t code could build software. And they could. Bubble, Webflow, Zapier and hundreds of other products proved that years ago.
But “can build software” covered a very wide range.
You could often build the interface. You could create workflows. You could connect a database. You could launch something useful. Where things became difficult was when the product stopped behaving like the standard thing the platform expected you to build.
The more custom the application became, the more expensive that final stretch became.
AI changed the beginning of that curve dramatically. Instead of learning a visual builder before seeing anything useful, someone can describe an idea and have a working version appear minutes later.
Coding agents accelerated that same shift even further, but mostly for developers. They made experienced developers dramatically faster, to the point where many are writing far less code by hand while shipping more software than ever. For non-developers though, those tools can still feel out of reach because they expect you to understand repositories, terminals, dependencies, deployment and the rest of the development environment. So while AI made the first version easier for everyone, it also widened the gap between what a developer can do with an agent and what a capable non-developer can comfortably control.
That’s incredible, but the first generation isn’t where I would judge these products anymore.
I would judge them by how far they can carry me after the first generation.
Can I change the architecture when the idea evolves? Can I deal with authentication properly? Can I connect the external service I actually need instead of choosing from three approved integrations? Can I understand what broke? Can I control deployment? Can I get the complete code out? Can somebody else continue the project without rebuilding everything?
Most importantly: can I get this close enough to a final product that bringing in a developer, if I eventually need one, becomes a targeted job rather than a rescue operation?
That is the shift I think Friday represents.
Coding agents like Claude Code and Codex already have an extremely high ceiling. In many cases they can build the whole application. But they still assume the person directing them understands development to some extent. Repositories, branches, environment variables, package managers, command lines, testing, logs, deployment and architecture are still part of the conversation.
A capable non-developer may understand the product perfectly and still have no interest in any of that.
Friday is putting a wrapper around a lot of those pieces.
PlugThis goes further in a narrow category and says you don’t even need to learn the extension stack first. The builder already understands it.
So I don’t think the future of no-code is simply “nobody writes code.”
The code is still there.
The more useful question for me is: how far can this tool take me toward a final product before I need to become a developer or bring one in?
That is a much higher bar than generating the first screen.
Featured Guide | Insider insights
The State of No-Code and AI App Builders
I recently went much deeper into this in my guide to no-code and AI app builders. I compared 26 different products across traditional visual no-code platforms, prompt-first AI builders, boilerplates and starter kits, and full coding agents.
The categories already overlap all over the place. Bubble and other traditional builders are adding prompt generation. Prompt-first products are adding Git, code access, authentication, databases and deployment. Boilerplates are being designed so coding agents can understand the project before they start changing it. Coding agents can now create entire products when you give them the right repository, requirements and access to the required tools.
My biggest takeaway from updating that guide wasn’t which builder generated the nicest demo.
It was what happened after the demo.
The first version has become incredibly cheap. Maintaining it, changing it precisely, understanding what the AI created and getting the application all the way to something you can confidently put in front of paying customers is still where the separation between these products becomes obvious.
This is why I think the middle of the market will become especially interesting.
A non-developer may not want the restrictions of a traditional no-code environment anymore, but moving directly into Claude Code can still be a big jump. There is room for products that expose more power gradually, wrap the ugly development plumbing, provide strong starting codebases and keep an escape hatch open when the project outgrows the original environment.
There is also room for more specialized builders like PlugThis. Instead of one AI builder trying to understand every possible application, we may end up with builders that know a specific stack, industry or application type extremely well and can take the user much further through that final stretch.
Read The State of No-Code and AI App Builders
I have written about the other side of this question too in Should Entrepreneurs Still Learn How to Code in the Age of AI?
I still think some technical understanding gives founders an enormous advantage. You don’t necessarily need to be the person writing every function, but you need enough judgment to describe what you want, recognize when the AI took a bad turn, test what it produced and know when the application has moved beyond what you should be reviewing alone.
There is a big difference between not writing the code and having no idea what the software is doing.
If I were building an AI app builder today, I’d focus on how far I can take a capable non-developer toward a finished product before they need to bring in a developer. Can I handle more of the Git, hosting, deployment and development setup for them? Can I give them strong starting points instead of forcing every project to begin from scratch? Can they keep refining the product, get to the underlying code when they need it, and eventually hand that code to a developer without starting over? That’s the direction I find interesting. The first working version is useless. The real opportunity is helping people keep going after that and making the next steps clear whithout assuming they know what a developer knows.
That is also why I think “no-code” is becoming a slightly strange description for this category.
Friday writes code.
PlugThis writes code.
Lovable writes code.
Claude Code obviously writes code.
From the user’s perspective, the interesting difference is no longer whether code exists. It is how much of the traditional software-development process they need to personally manage before they can get the result they want.
Five years ago, a founder might hire somebody just to turn an idea into the first working version. Today that founder may be able to build the first version over a weekend.
The next battle is who can get them to the finish line on their own.
The edge cases. The integrations. The changes nobody thought about in the first prompt. The deployment. The handoff. The parts that separate an impressive demo from software somebody can actually use.
That’s the final 10 to 20%.
And I suspect we’re going to see a lot more products built specifically to close it.
Friday and PlugThis are forging the path in this middle ground.
There is still one thing none of these builders can do for you though.
They can make building much easier.
They still can’t decide whether the thing you’re building is worth building in the first place.
More soon,
Abe
Whenever you’re ready, there are 2 ways I can help you:
- Professional Review: Get your app or website reviewed by me. Apply Now
- Work with me 1:1: After evaluating more than 1,000 SaaS products, I know what makes buyers pick one over another. I help you get those differentiators right and make a better mousetrap, the kind that sells. Apply Now
|
Join 10K+ readers of Before You Build, the newsletter for Strategic SaaS Founders who want to decide what is worth building, make it meaningfully different, and turn it into something people want to buy. |
No spam. Just practical lessons from evaluating hundreds of SaaS products and helping founders make better product decisions.