infra first

plan:
  build a product

what happens:
  build a product
  realize you're actually building a library
  realize the library needs a protocol
  realize the protocol needs a runtime
  ...
  you're building infrastructure now

some people naturally build products. some people naturally build infrastructure.

not ci/cd. not deploy scripts. actual infra products. libraries. frameworks. protocols. runtimes. the layers that other people build on top of.

i start a project thinking “this is a product.” within days, the interesting part isn’t the product. it’s the thing underneath. the reusable piece. the layer that could power ten other products.

the pull

it’s not a conscious choice. it’s a gravitational pull.

you’re building an app and you write a module to handle something. the module gets interesting. more interesting than the app. you start generalizing it. cleaning the api. making it work for cases beyond your own. suddenly you’re not building an app anymore. you’re building a library.

or you start a tool for yourself. someone else wants to use it. you add an interface. then a config format. then plugin support. what started as a script is now a platform.

product thinking:   "what does the user need?"
infra thinking:     "what does the builder need?"

both are valid. but they’re different games.

when to ship the product

shipping fast is real. most of the time, the right move is to push through, get the thing in front of users, and iterate. a product on shaky foundations that ships today beats a perfect framework that ships never.

if you’re validating an idea, finding market fit, or racing a deadline: ship the product. don’t abstract. don’t generalize. solve the concrete problem and move on. most startups are just chats, lists, or spreadsheets anyway.

this is good advice. and it’s true.

when to build the layer underneath

but sometimes the concrete problem is the layer underneath.

you start building a product and realize the real value isn’t the ui or the features. it’s the engine. the data model. the protocol. the thing that, if it existed as its own project, would make this product trivial to build - and five other products too.

product_value  = users * usage * lifetime
infra_value    = products * builders * years * (1 + compound_rate)

products serve users. infrastructure serves builders. when you find yourself building something that other builders could use as a foundation: pay attention to that instinct.

the accidental infra product

some of the best infrastructure wasn’t planned as infrastructure. it started as a product, or a feature inside a product, and evolved.

linux started as one student’s operating system. rails started as the framework behind one app. react started as facebook’s internal rendering solution. docker started as an internal tool at a PaaS company.

day 1:     "solving my own problem"
day 90:    "other people have this problem too"
day 365:   "this is a platform now"

the pattern repeats: someone builds a product, extracts the interesting layer, and that layer becomes bigger than the product ever was.

you don’t have to choose between product and infra upfront. sometimes you build the product and the infra reveals itself. sometimes you think you’re building one thing and you’re actually building the other.

know which game you’re playing

the industry worships products. features. the stuff you can demo and screenshot. and most of the time, that focus is right.

but some people keep drifting toward the layer underneath. not because they can’t ship products. because they see the leverage in building what other builders stand on.

both games are worth playing. the skill is recognizing which one you’re actually in.

sometimes you build the house. sometimes you build what houses are made of. and sometimes the house turns into a building material on its own.