Hacker News Reader

Comment by transitivebs | Hacker News Reader

If you're architecting an early-stage startup, this article covers almost nothing of worth.

The two most important architectural factors for early-stage startups are:

1. product velocity; eg, the ability to move fast, experiment, and try things out in prod.

2. resource modeling; eg, what are the core data models that your product will use and how do they relate to each other?

Everything else is noise until you hit P/M fit.

#2 is less important than #1, but it's the really the only design point that can make or break ease of scalability post-P/M fit.

View on HN

Yep! And to add to #1 I've seen people choose poorly and then write really bad code to make-up the velocity lost by the poor choice, and then see this as a virtue (eek!). A good choice should allow you to write fairly decent code, as it's natural to do so exactly because you chose a tech stack that fits the problem space! And if you're not quite sure what the problem space is, that means choosing a flexible tech stack and avoiding giant and costly assumptions.

Plus, they miss a key point of architecture: sustainability. You might take the 30’ somewhere and draw a high-level model like the ones depicted in the article, but who has time to continuously validate that devs actually follow the blueprint and make decisions should a need to change emerge? Nobody. And that’s OK. Architecture is not a magical ding an sich to be pursued but a way to organize things to achieve specific strategic goals. And for a startup, that goal is to survive until the liftoff. This survival very seldom involves investing heavily into architecture. Some experienced devs are going to be fine, neither the business nor the organization nor the system is going to be complex enough to merit dedicated attention to architecture. And if they are, something is wrong elsewhere (typically leadership)

> ding an sich

To be fair, while I never expected Kant to get involved in startup thinking, architecture as (not) a goal in itself is a very good point.

Could you elaborate a bit more on #2? What would be the implication of good/bad resource modeling.

Not GP, but an idiosyncratic data model that reflects a non-reality really encumbers momentum by introducing integration friction, arguments on the “right” way forward and generally causes a lot of noise. It can also make the team look like bozos when explaining the model to outsiders.

Isn't the operations behind Cockroach make velocity quicker? It takes care of alot of stuff for me. Have you tried the opensource version?

what's the general guide for #1? monolith app, schemaless database?

I think rather than optimise the application architecture optimise the tool chain, for rapid deployment, partial changes, blue/green deployments, etc. A hard separation between front and back ends is good too, so there can be a good UX but smoke and mirrors behind the scenes.

Reply on news.ycombinator.com