Engineers at our startup don't build features anymore
21 comments
I have never heard of this approach. It does sound interesting in theory, but I have a hard time seeing this work beyond the simplest of CRUD apps.
My initial concerns would be:
- Maintainability: the "duct-tape logic", as you put it, sounds like spaghetti code from hell. Making sense of a feature comprised of tons of chained third party calls will be a nightmare.
- Expressiveness: complex functionality may require complex code. I don't quite understand how you would write even medium complexity algorithms using this system.
- Reliability and performance: you are now entirely at the mercy of third party providers. This is often the case with SaaS products, but this seems like a particularly severe case. Each hop reduces performance as well, which may impact user experience (assuming we're talking about user-facing features).
- Quality: by moving business logic out of code, you're throwing out testability, so no more unit tests. I guess integration tests could still happen, but they're going to be slow, expensive, and involve someone writing the actual code - which, given the premise of product managers creating features, seems very unlikely.
My initial concerns would be:
- Maintainability: the "duct-tape logic", as you put it, sounds like spaghetti code from hell. Making sense of a feature comprised of tons of chained third party calls will be a nightmare.
- Expressiveness: complex functionality may require complex code. I don't quite understand how you would write even medium complexity algorithms using this system.
- Reliability and performance: you are now entirely at the mercy of third party providers. This is often the case with SaaS products, but this seems like a particularly severe case. Each hop reduces performance as well, which may impact user experience (assuming we're talking about user-facing features).
- Quality: by moving business logic out of code, you're throwing out testability, so no more unit tests. I guess integration tests could still happen, but they're going to be slow, expensive, and involve someone writing the actual code - which, given the premise of product managers creating features, seems very unlikely.
N8n is pretty powerful in that you can pipe Kafka streams into there for webhook trigger functions, separate postgres DBs can be set up for non-eng and also all the production API endpoints can be called from there in a tracable way.
This is not the new normal.
Engineering should be doing the engineering.
Product should be doing product.
DevOps should be providing infra.
If end users want to use a report generator or setup a notification rule that's one thing but duct taping features together never is sustainable.
Engineering should be doing the engineering.
Product should be doing product.
DevOps should be providing infra.
If end users want to use a report generator or setup a notification rule that's one thing but duct taping features together never is sustainable.
Why is the siloing so important do you think? I think with all the use of LLMs now, entire functions or multiple functions can be done by 1 person. Those people can get a lot of task and skill variety in their work.
Every team member has a job to do in the software process. Each speciality can leverage AI to perform faster and better moving the whole process forward. I think everyone can expand outward with what they are able to do enhanced by AI but they need to stay around their core expertise where they are bringing the most value. Things still need to be maintainable and secure.
My mental model of the 'new normal' is end users using AI to get their work done.
So if I re-worded the OP's description and replaced 'internal tools' with 'internal AIs' then this would at least seem like a more reasonable process to me...
> At our startup, engineers don't build features anymore. > They build APIs that internal AIs can connect to. > Most "features" like running an SQL query, sending a push notification when product X is ordered gets built by ops or product folks using those tools.
To me this describes a team of engineers that use AI-capable tools and that are building 'features' for themselves. In the way that us dinosaurs used to write build scripts.
I'm not saying that my mental model is right or wrong, just that working this way seems reasonable if you buy into my model.
So if I re-worded the OP's description and replaced 'internal tools' with 'internal AIs' then this would at least seem like a more reasonable process to me...
> At our startup, engineers don't build features anymore. > They build APIs that internal AIs can connect to. > Most "features" like running an SQL query, sending a push notification when product X is ordered gets built by ops or product folks using those tools.
To me this describes a team of engineers that use AI-capable tools and that are building 'features' for themselves. In the way that us dinosaurs used to write build scripts.
I'm not saying that my mental model is right or wrong, just that working this way seems reasonable if you buy into my model.
Definitely ...
If anything engineers are doing more with AI and aren't limited to just APIs.
They are building more of the UI/UX, Design, Front/Back + API instead of less and meeting/building product's vision.
Supported by Devops.
Every layer of the process will be enhanced by AI so everyone is doing more that our previous process.
I wouldn't limit any layer, enable everyone and every team to do more and be more productive.
If anything engineers are doing more with AI and aren't limited to just APIs.
They are building more of the UI/UX, Design, Front/Back + API instead of less and meeting/building product's vision.
Supported by Devops.
Every layer of the process will be enhanced by AI so everyone is doing more that our previous process.
I wouldn't limit any layer, enable everyone and every team to do more and be more productive.
This is a fascinating model, thanks for sharing. The classic "engineering as the bottleneck" problem is something every product engineer feels, so I deeply appreciate the desire to solve it.
I'm intrigued by this API-first approach, and it's left me with a few questions from my perspective as an engineer who builds product features:
How do you handle features with complex UI/UX? While a push notification is a perfect fit, how would a non-eng person build, say, a new analytics dashboard with interactive charts or a multi-step modal view? Is there a clear line where a feature's complexity means it has to go back to the engineering team?
Who owns the holistic user experience? With different people building features decentrally, how do you ensure the product feels cohesive and not just a collection of disconnected Zapier flows? I imagine maintaining a consistent design system and user journey could be a challenge.
You mentioned the "duct-tape logic" problem. This is the part that resonates—and worries—me most. Do you have a formal process for refactoring or "graduating" a successful duct-tape solution into a core, robust, engineer-built API? How do you manage that accumulating technical debt?
As an engineer, the idea of focusing solely on clean, scalable APIs is incredibly appealing. At the same time, there's a certain joy in crafting and shipping a polished feature directly to users. It's a really interesting trade-off you've presented.
Thanks again for the thought-provoking post.
I'm intrigued by this API-first approach, and it's left me with a few questions from my perspective as an engineer who builds product features:
How do you handle features with complex UI/UX? While a push notification is a perfect fit, how would a non-eng person build, say, a new analytics dashboard with interactive charts or a multi-step modal view? Is there a clear line where a feature's complexity means it has to go back to the engineering team?
Who owns the holistic user experience? With different people building features decentrally, how do you ensure the product feels cohesive and not just a collection of disconnected Zapier flows? I imagine maintaining a consistent design system and user journey could be a challenge.
You mentioned the "duct-tape logic" problem. This is the part that resonates—and worries—me most. Do you have a formal process for refactoring or "graduating" a successful duct-tape solution into a core, robust, engineer-built API? How do you manage that accumulating technical debt?
As an engineer, the idea of focusing solely on clean, scalable APIs is incredibly appealing. At the same time, there's a certain joy in crafting and shipping a polished feature directly to users. It's a really interesting trade-off you've presented.
Thanks again for the thought-provoking post.
I like to point back at an ancient pattern in engineering: prototypes.
Prototypes are built to learn. They're not optimized nor efficient. They don't scale. They discover what needs to be built and are then thrown away. They should not be sold into production. Learning also includes getting user feedback, or finding out whether all the systems play together well.
Once the prototype is valid, pass it to an engineer to build it in properly and efficiently.
Another variation might be turning the engineers into ops. I did that early on at a startup. We built the whole delivery management system in 3 days - who ordered what, the state of it being delivered (packed/in delivery), informing buyers of product tracking number, asking them whether it was received in good condition, flagging things that have exceeded delivery time, etc. This was before AI and I built it so damn fast because it's a pain to handle this process on spreadsheet. The downside was that orders in those 3 days were delayed by 3 days.
But the big downside to engineers doing these is that you have to pay them engineer salaries. If it leads to a world where marketers can be given engineer salaries and engineers can be given marketing jobs, maybe we're in a better place?
Prototypes are built to learn. They're not optimized nor efficient. They don't scale. They discover what needs to be built and are then thrown away. They should not be sold into production. Learning also includes getting user feedback, or finding out whether all the systems play together well.
Once the prototype is valid, pass it to an engineer to build it in properly and efficiently.
Another variation might be turning the engineers into ops. I did that early on at a startup. We built the whole delivery management system in 3 days - who ordered what, the state of it being delivered (packed/in delivery), informing buyers of product tracking number, asking them whether it was received in good condition, flagging things that have exceeded delivery time, etc. This was before AI and I built it so damn fast because it's a pain to handle this process on spreadsheet. The downside was that orders in those 3 days were delayed by 3 days.
But the big downside to engineers doing these is that you have to pay them engineer salaries. If it leads to a world where marketers can be given engineer salaries and engineers can be given marketing jobs, maybe we're in a better place?
What do you think about every single employee at the company being an engineer and picking up a domain or two (finance, accounting, digital marketing, support, sales)? The founder of Telegram talks about how he just has a company with 30 engineers and no other staff.
I like it and it suits my skills. It's more a question of whether this is practical. Are they enough people who like this configuration? Because I'm sure bored of looking at the same piece of code day after day and trying to figure out what people want.
Sounds quite similar to how running an internal dev shop in an enterprise environment used to be, before SaaS apps took over. "Power users" would write basic apps in SharePoint, Domino, Business Objects, or other such "low-code" platforms... even Salesforce in its early days. It worked fine for department-level CRUD/LOB apps. If anything they were doing grew and became important enough that their lack of engineering skills became a problem, us IT folks would come in, take over the app, refactor it, and make in an officially supported app. But we would have hundreds of half-baked apps out there that were good enough to handle the small stuff that small business groups needed. We focused on keeping the platforms up to date, running well, setting up various data they could query, etc.
Has anyone else tried this kind of setup?
Yes.
We don’t even have the budget to hire non-technical people for tech products. Everybody gotta code. We also avoid feature bloat.
We focus only on core features. If someone has an idea and can build it, they’re welcome to try. But most ideas won’t make it to production.
Yes.
We don’t even have the budget to hire non-technical people for tech products. Everybody gotta code. We also avoid feature bloat.
We focus only on core features. If someone has an idea and can build it, they’re welcome to try. But most ideas won’t make it to production.
What do you think about every single employee at the company being an engineer and picking up a domain or two (finance, accounting, digital marketing, support, sales)? The founder of Telegram talks about how he just has a company with 30 engineers and no other staff.
That model may work in the earliest days of a startup — but it usually breaks down as the company grows. Here’s why:
- Focus matters. Engineers need deep focus to build and scale. At the same time, finance/accounting and sales require their own level of expertise and dedicated attention. You can’t just “dabble” in those areas and expect excellence — especially when it comes to things like serious fundraising, investor relations, closing multi-million dollars contracts, financial compliance, etc.
- Scaling with only engineers creates organizational fragility. As headcount grows, managing a company full of only one type of thinker becomes a liability. It lacks diversity of thought, skills, and experience. Think of it like trying to build a tower using only one material — it may stand for a while, but it won’t last.
- Burnout and inefficiency. Expecting engineers to wear too many hats leads to mental overload and a lack of accountability. Critical tasks fall through the cracks, and product quality can suffer.
- We’ve made that mistake. Over a decade ago, we had a habit of sharing everything with everyone in the company. But too much information flow killed focus. We eventually realized it’s the founder’s job to shield the team and protect the company from unnecessary distractions — including over-informing investors or team members on things outside their scope.
- Top non-engineers can be game-changing. A brilliant finance or sales person can be just as valuable — sometimes more valuable — than an engineer. Especially in areas like revenue growth, closing deals, or keeping the company alive through smart financial planning.
- Note that excellent engineers don't want to do finance, sales, etc. and vice versa.
Bottom line: engineers are core for tech company, but they’re not everything. Great companies are built by teams.
Don’t try to reinvent the wheel — unless your company exists to build a better wheel.
- Focus matters. Engineers need deep focus to build and scale. At the same time, finance/accounting and sales require their own level of expertise and dedicated attention. You can’t just “dabble” in those areas and expect excellence — especially when it comes to things like serious fundraising, investor relations, closing multi-million dollars contracts, financial compliance, etc.
- Scaling with only engineers creates organizational fragility. As headcount grows, managing a company full of only one type of thinker becomes a liability. It lacks diversity of thought, skills, and experience. Think of it like trying to build a tower using only one material — it may stand for a while, but it won’t last.
- Burnout and inefficiency. Expecting engineers to wear too many hats leads to mental overload and a lack of accountability. Critical tasks fall through the cracks, and product quality can suffer.
- We’ve made that mistake. Over a decade ago, we had a habit of sharing everything with everyone in the company. But too much information flow killed focus. We eventually realized it’s the founder’s job to shield the team and protect the company from unnecessary distractions — including over-informing investors or team members on things outside their scope.
- Top non-engineers can be game-changing. A brilliant finance or sales person can be just as valuable — sometimes more valuable — than an engineer. Especially in areas like revenue growth, closing deals, or keeping the company alive through smart financial planning.
- Note that excellent engineers don't want to do finance, sales, etc. and vice versa.
Bottom line: engineers are core for tech company, but they’re not everything. Great companies are built by teams.
Don’t try to reinvent the wheel — unless your company exists to build a better wheel.
The hardest part is a good authz system.
Code is data but now no data is code.
this only works for very early stage
At what point do you think it starts to stop working?
this approach is cool for speed and small teams but duct-taping features with low/no code tools quickly gets messy. you lose the deep control engineers provide and debugging complex flows turns into nightmare mode. also testing? good luck with automated tests when your logic is scattered across 5 different services and zapier chains.
scaling this needs discipline or you’ll end up with a brittle spaghetti monster nobody wants to touch.
it’s a neat hack but definitely not the new normal for anything beyond MVPs or tiny startups.
it’s a neat hack but definitely not the new normal for anything beyond MVPs or tiny startups.
If you've got the idea, you build and ship it yourself. It's fast, empowering and it keeps engineers focused on building a reliable, scalable, secure set of APIs. It also forces us to write better, cleaner APIs and the APIs stay stateless and focused. Debugging can be hard and sometimes duct-tape logic quietly piles up.
I think it's better than the usual model where eng is the bottleneck for every new flow. Has anyone else tried this kind of setup? Where does it fall down or is it the new normal?