S

HomeAboutBlogs

How I Built 120+ Projects Without Reinventing Everything

Shipping a high volume of projects is less about heroics and more about refusing to reinvent the boring parts every time.

Published on December 19, 2025

How I Built 120+ Projects Without Reinventing Everything

People hear “120+ projects” and picture a montage: late nights, blank repos, genius under pressure. The real story is duller and more useful. Most of the work stops being new after the tenth time you solve auth, tables, uploads, and empty states.

I did not invent a new product category for every engagement. I built a reuse habit — architecture that travels, components that do not fight you, and a design system that keeps the first week from becoming a fashion debate.

Invent where it matters. Reuse everywhere else.

Layer 1 — The skeleton that never changes much

Every serious project needs a boring spine early: repo structure, env handling, CI that can deploy, auth middleware, API patterns for list / detail / mutate, logging that someone will actually read. If you rebuild that spine from intuition each time, you are paying tuition forever.

My version of reuse is not a sacred monorepo religion. It is a set of defaults I trust enough to start from — then bend. The goal is not identical apps. The goal is identical week-one decisions so week two can be about the client's actual problem.

Auth shows up again. Pagination shows up again. Role checks show up again. File uploads show up again. Email sending shows up again. These are not where a product differentiates. Treating them as unique every time is how calendars vanish.

Layer 2 — Components that earn their keep

Reusable UI fails when it tries to be clever. It works when it covers the dull majority: forms with validation states, data tables with filters, modals that behave, toasts that do not invent a new personality each sprint, layouts that keep spacing consistent.

I keep the library small on purpose. A component that needs a dissertation of props is usually two components pretending to be one. A component that only exists for one project should stay local. Reuse is a tax system — you only extract when the second and third copies prove the pattern.

The win is not “we have a design system.” The win is opening a new project and not spending Monday arguing about button padding while the real workflow is still a sketch.

Layer 3 — Design tokens before design drama

Color, type scale, spacing, radius, elevation — decide once, apply everywhere. Not because every product should look the same. Because debates about a 2px difference burn hours that never show up in the demo. Tokens make brand variation cheaper: swap the skin, keep the skeleton.

Agencies feel this acutely. Product teams feel it too once the third designer joins. A lightweight system beats a PDF style guide nobody opens. Tokens are boring until you watch a team without them thrash for a day over shades of gray.

Layer 4 — Patterns, not paste

Copy-paste reuse rots. Pattern reuse travels. Pagination that always works the same way. File upload that always surfaces the same failure modes. Permissions checked in the same layer. When the pattern is shared, the next project inherits judgment, not just files.

This is how volume becomes possible without quality collapsing into chaos. You are not faster because you type less. You are faster because fewer decisions are novel. Novelty is reserved for the domain — the weird workflow, the business rule that only this client has, the screen that is the whole reason the engagement exists.

What I refuse to reuse

Domain logic. Weird workflows. The one screen that is the whole reason the project exists. If you reuse the special thing, you sand off the reason someone hired you. Reuse the plumbing. Handwrite the value.

I also refuse to reuse bad compromises. If a pattern only worked because a previous project was scared of refactoring, it does not graduate into the kit. Reuse should accumulate taste, not fossils. A foundation that only exists because “we always do it this way” is how factories of mediocre clones get born.

Brand expression stays unique on purpose. Voice, visual identity, the metaphor of the product — those should not feel templated. Foundations should. Confusing the two is how everything becomes beige or everything becomes bespoke chaos.

High volume is a systems problem. Hero mode does not scale. Defaults do.

The 120+ number is not a flex about suffering. It is evidence that reusable architecture, components, and design systems beat starting from zero every time. You still have to think. You just stop thinking about the same checkbox twice.

If your next project begins with a blank folder and a philosophical debate about folder names, you are not at the hard part yet. You are still paying for the absence of a kit. Build the kit once. Bend it forever. Invent only where invention is the product.

Need a product built without reinventing the boring spine first?hello@replikatech.com