28 JUN 2026Frontend Development · Building · Reflection

How I actually build things

I never really sat down to think about how I build until someone asked me. Here is what I found.

I never really sat down to think about my building pattern until recently. I just built things. But looking back across everything, from fintech dashboards to a flyer tool to an npm package, there are some things I keep doing without planning to.

Step one is always the stack

Before I write a single line of code, I mind map the stack.

thinking

Not just "what framework do I want to use" but what makes sense for this specific project, what is actively maintained right now, what are the current updates on each piece, what is the accessibility of each tool for the problem I am solving.

This is non negotiable for me. I have seen what happens when you pick a stack without thinking. You end up fighting your tools instead of building your product.

I learn by need, not by curriculum

My stack did not come from a roadmap. It came from projects pulling tools out of me.

HTML, CSS, JavaScript first because that is where everything starts. Then React because it made sense for what I was building. Then Svelte because I felt opportunities were moving that way. Then Angular because it was tough and I wanted to know what tough felt like. React Native on the job. Flutter to complete the mobile picture. Node, Postgres, Firebase, Docker, each one because a project needed it.

No course told me to learn these in this order. Every tool has a reason behind it.

I ship when nothing is visibly breaking

shipping

Which sounds irresponsible but hear me out.

Something is always quietly broken somewhere. If I waited until everything was perfect I would never ship anything. The real question is whether the broken thing is visible to the user right now. If not, ship it. Fix it in the next version.

I build blocks, not screens

This one I do without thinking every single time.

Before I build any screen I set up the full component architecture. Libs, utils, UI components, all properly separated and entirely reusable. I do not build a dashboard. I build the table component, the card component, the modal component, and then the dashboard assembles itself from those pieces.

The benefit is I can pick code from old projects and drop it into new ones cleanly. Pieces from Waysdrop have ended up in Fillyr. Components from one contract project have shown up in the next. Nothing gets thrown away.

I extract before I repeat

The clearest example of this is @dalgoridim/headless-cms.

I built inline editing into my first portfolio. Then I was about to build a second one and realized I would have to move all that logic across. So instead of copying it I pulled it out, made the backends pluggable, and published it as a standalone package. Then rebuilt both portfolios on top of it.

reuse

Same thing happens with components across projects. If I find myself building something for the second time it becomes a utility or a shared component.

I got calmer under fire

Early me panicked hard when things broke in production. Current me still feels it. But I plan better now. Staging environments before schema changes. Backups before migrations. Contingency before incidents, not after.

Production has a way of teaching you things no tutorial covers. I have the scars to prove it.

The pattern in one line

Research before committing. Build blocks before screens. Ship before ready. Extract before repeating. Get calmer each time something breaks.

That is basically it. Everything else is just those five things applied to different problems.