Three Ways Software Gets Built Now, and Why the Lines Keep Blurring
A mid-size logistics company recently replaced a scheduling process that involved three spreadsheets, a shared inbox, and a daily fifteen-minute call just to sync information. They didn’t hire developers. An operations manager built a replacement in Glide over two weekends. It’s not pretty, but it works, and the daily call is gone.
That story would have been unusual five years ago. It’s becoming ordinary.
The Traditional Development Path Isn’t Disappearing, But Its Role Is Narrowing
Custom-coded software still makes sense in specific situations. Complex integrations, high transaction volumes, proprietary algorithms, anything where performance and control matter enough to justify the cost and timeline. A fintech startup building a payment processing layer isn’t going to do that in a no-code tool. Neither is a healthcare company managing compliance-sensitive data pipelines.
But a lot of business software development doesn’t fall into those categories. Internal tools, client portals, workflow automation, reporting dashboards, approval systems. These are the kinds of applications that used to get queued behind more strategic projects and waited months for developer time. Now they don’t have to.
The consequence of this shift is that development teams are gradually getting freed from low-complexity internal requests. Whether that’s actually happening depends on the organization, but the potential is real.
No-Code Grew Up
Early no-code tools were fine for simple forms and basic automations. The current generation is meaningfully more capable. Bubble handles relational data and user authentication. Retool connects to existing databases and APIs and lets non-technical operators build internal dashboards that would have required a React developer two or three years ago. Glide turns spreadsheets into mobile apps.
No-code AI app builders have added another layer, letting users describe what they want and get a working structure without manually configuring every component. The results vary, but the ceiling is higher than most people who haven’t looked recently would expect.
The honest limitation is still complexity and scale. No-code platforms make the first eighty percent of a build much faster. The last twenty percent, the edge cases, the custom logic, the performance tuning, can still require real technical skill, or you hit a wall the platform wasn’t designed to handle. Knowing that going in helps you pick the right tool for the right job rather than discovering the constraint six months into a build.
AI Has Changed the Calculation for People With Some Technical Skill
This is where things get interesting. The productivity gains from AI are most pronounced for developers who already know what they’re doing. Someone who understands software architecture but would normally spend hours on boilerplate can now move significantly faster. That’s the group seeing the most dramatic change in output.
For people with partial technical knowledge, the picture is more complicated. AI can help them build things they couldn’t before, but it can also help them build things they don’t fully understand. That gap matters when something breaks, when the requirements change, or when someone else has to maintain it. The code exists, but the understanding doesn’t always come with it.
This isn’t an argument against using AI. It’s an argument for being honest about where your understanding ends and where you’re trusting output you can’t fully evaluate.
The Decision That Actually Matters
Most organizations aren’t choosing between no-code, AI, and traditional development as philosophies. They’re making a series of individual decisions about specific projects, and the right answer depends on the complexity of the problem, who’s available to build it, how long it needs to last, and what happens when something goes wrong.
A sales team that needs a custom CRM view probably doesn’t need a developer. A company building a customer-facing application that will process thousands of transactions a day probably does. The mistake is applying the same approach to both because it worked for one.
What’s shifted is that the range of problems solvable without a professional development team has expanded substantially. That creates real options for businesses that previously had none. It also creates a new kind of decision-making burden: figuring out which approach fits which problem, rather than defaulting to one path because it’s the only one available.
The organizations doing this well aren’t the ones that picked a favorite tool. They’re the ones that got better at matching the build approach to the actual requirements of the thing being built.
