Engineers at our startup don't build features anymore

Post by PaulShin » Thu, Jun 19, 2025, 9:40 AM UTC

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.

Post by VivaTechnics » Fri, Jun 20, 2025, 3:10 AM UTC

s4293918 wrote: post #15

VivaTechnics wrote: post #10

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.

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.

Re: Engineers at our startup don't build features anymore

Re: Engineers at our startup don't build features anymore