Engineers at our startup don't build features anymore

8 s4293918 8 6/16/2025, 1:03:52 PM
At our startup, engineers don't build features anymore. They build APIs that internal tools like Zapier, Make and N8n 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.

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?

Comments (8)

romanhn · 9h ago
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.

saluki · 6h ago
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.

emorning3 · 4h ago
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.

codingdave · 7h ago
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.
VivaTechnics · 3h ago
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.

codingwagie · 7h ago
this only works for very early stage
revskill · 5h ago
The hardest part is a good authz system.
revskill · 8h ago
Code is data but now no data is code.