[ MAIN IDEA ]

Occasionally I’ll run into a fellow unemployed indie dev who is actually focused on a single project. Once I find this out, I always ask this question excitedly:

”What’s your runway?”

So far, I’ve never gotten a straight answer. Instead, what follows is a ramble about how their wife is supporting them for “a little bit,” how they can sell some crypto, and how they can probably go back to their old job and moonlight if things flop.

I used to get so frustrated that I’d jump in --

“No, I mean how long until you run out of money??”

That only elicited even longer rambles, this time about their 401k rollover, their history as a consultant, their HSA, their father-in-law’s welding business, Airbnb, and property taxes.

I finally realized this:

Bootstrappers don’t know their runway.

“Runway is for those YC companies,” they think.

No, runway is for us way more than it is for them.

That’s because if you don’t know your runway, your financial decisions are driven by your emotions, which is bad.

So here’s how to figure out your runway as a bootstrapper.

Part I: Get your numbers

1. How much are you losing? Add up last month’s expenses (business + personal) so that you have one number.

2. How much is coming in? Add up last month’s income after taxes. One number.

3. What’s the gap? Expenses - Income.

4. How much do you have? Add up the cash and assets you’re willing to part with.

Part II: Divide

1. Cash (#4) ÷ Gap (#3). That’s how many months you have.

2. Multiply that by 30 if you want it in days.

Now you know your runway.

This’ll help you see how big of an impact your lifestyle has on your startup’s success. Let’s look at a few scenarios; you’ll see what I mean.

Founder A is confident, because he’s sittin’ on $100k cash from an IPO. But he spends $15k each month, and has nothing coming in.

100,000 / 15,000 = 6.6 

Hotshot has less than 7 months of runway.

Founder B is young and broke, but frugal. He set aside $3,000 before getting laid off. He’s spending $1,500 and makes $800 from landscaping on the side. His gap is $700.

$3,000 / $700 = 4.3

The hotshot founder with a hotshot lifestyle only has two months more runway than a broke kid with a landscaping job!

Founder C got things off the ground before quitting her job. She’s spending $4,000 but earning $3,000. Her gap is $1,000. She’s got $20,000 stashed away.

$20,000 / $1,000 = 20

20 months of runway! 600 days to figure out how to earn an extra $1,000 and become ramen profitable. Founder C has 1/5 of the cash of Founder A, but over 3X the runway.

It’s wild to see all the gibberish in your head reduced to one number, isn’t it?

Clarity is king.

Although it’s initially scary, I find that tracking this number is empowering.

It reminds you that you always have two levers: make more money, or spend less money. Hotshot Founder A could triple his runway by making $5k recurring revenue more next month. Or he could make $0 and triple his runway by downsizing to a smaller apartment.

If you don’t like your runway, you can cut expenses, pick up consulting work, charge more, or pivot. These are all rational responses to a financial reality.

It also keeps your emotions in check. Bumping into a high school friend who got a Big 4 Job and just bought their second Audi doesn’t spike your FOMO anymore; you already confronted the reality of your decisions in a spreadsheet that morning.

So whether you’re sitting on a mountain of cash or scavenging for change, please calculate your runway, if only to make our conversation more enjoyable for me when we bump into each other.

[ INSPO ]

[ MAIN IDEA: SIMPLE PAYMENTS ]

In 2004, Howard Wein started selling Philly cheesesteaks for $100 each.

In 2013, Nipsey Hussle sold 1,000 mixtapes for $100 each.

In 2014, he sold 100 for $1,000 each.

In 2023, MSCHF sold a microscopic 3D-printed handbag for $63,750.

This blew my mind.

But after thinking about it, it started making sense.

They may have been offering similar products to their peers, but they were playing an entirely different game.

Howard was challenging your perspective on classic food.

Nipsey was using music as a funding mechanism to uplift his community.

MSCHF was leveraging clout to highlight our insatiable appetite for status and small handbags.

These creators knew they were doing things differently, so they refused to market and price themselves like commodities.

We devs should take notice, because our traditional funding sources are empty at their core.

• Deal sites like AppSumo enroll you in a race to the bottom, where you’re selling lifetime deals for $29

• Launching an NFT involves a lot of education and convincing people you won’t rug pull

• VC often requires you to trade your soul and control for time.

• Raising from friends & family exposes the wholesomeness of your relationships to the brutality of the marketplace.

But what if, like those creatives above, we took a different path?

What if we found a few people who valued our stuff so much that they’d be willing to pay 100X what a normal user would?

That’d change things, a lot.

You could make it insanely useful for them.

Suddenly you have daily users who really care.

They’re emotionally invested, so they give better feedback and are less demanding.

With that extra profit, you can reinvest in improving the product, support, and your local community … while also having enough left over to feel stable enough to shoo away those VCs who tempt you with a quick flip.

Your perception of yourself improves. Most importantly, you keep your soul — the pure essence that gave you the courage to start in the first place.

It sounds too good to be true.

Well, I figured I’d find out for myself if this theory holds weight.

[ THE STACK ]

So today my goal was to create a high-ticket offer — the simplest way I could.

No fancy landing page, no pipeline of automations, no ads, no images, no analytics, no funnels.

Just a blog post and Calendly.

Here’s how it works:

• The blog post explains the offer. Here it is for reference: https://www.compasscalendar.com/blog/crew

• There are two CTA links in the post that redirect to Calendly. Part of the offer is a call with me, so I wanted people to book it directly without adding a delay or another step.

• Calendly requires payment before finalizing the meeting. I connected Calendly with Stripe, so payments get tracked there. I didn’t even have to create a new Stripe product to set this up.

• When someone books, I get an email from Calendly and the money. Calendly handles the reminders, and then I just have to worry about fulfillment, which requires me to send a physical CD in the mail.

This whole project took fourteen hours, but eleven of those were crafting the offer and refining the copy. So if you already know what you’re selling, you could copy-paste this approach and be live in three hours.

I didn’t have to fuss with ads, product demos, screenshots, or high-res pictures. Just words, a link, a $12 subscription, and a few integrations.

That’s not bad!

Will the offer work? I guess we’ll see. Either way, it’s pretty cool that you can go from having an idea to having a way to monetize it in one day.

[ INSPO ]

In the last seventeen days, I’ve merged 266 Compass Calendar PRs. That’s 16 per day, a 14X increase since June.

One reason why I feel comfortable pushing so much code is that I enforce simplicity in each PR. Here’s how:

• A “/simplify” skill runs on every PR, which creates a commit that reduces complexity. Since this is a new commit, I can review it to ensure that we’re preventing sloppy abstractions.

• A PR template has a “Simplicity” heading, where the agent has to explain what was simplified or why the implementation is already minimal.

• My system prompt explains the supreme value of simplicity.

• I do a manual sweep of the code and keep a list of things I want simplified, and then kick off another session

Basically, I’m letting the agent do the first implementation. Then I’m nagging it to simplify things without breaking tests. Then I’m nagging it again to simplify it further.

It’s the equivalent of Henry Kissinger repeatedly asking his assistant, “Is this the best you can do?” before reading a draft. After a few rounds of revisions, the assistant eventually spats back, “Damn it, yes, it’s the best I can do!” Kissinger replies, smugly, “Fine, then I guess I’ll read it this time.”

When your assistants’ tokens are less expensive than your time, why not set a high bar before reviewing yourself?

If you’ve found a clever way to keep things simply, reply here to LMK.

[ INSPO ]

[ MORE ]

Kissinger: a biography (archive.org)

https://berkshirehathaway.com/ — the conglomerate that has enough money to buy half the internet hasn’t veered from its 90s aesthetic of blue font and direct links.

https://telegram.org/ — A consumer messaging app that doesn’t try too hard. The combination of simple text and whimsical rubber ducks is eye-catching without being try-hard. If one of the top 5 most-downloaded apps in the world can get away with this, so can you.

https://yaml.org/ — A site that’s structured to mirror a real YAML document. A great example of how to break out of the generic WordPress or technical doc site layouts.

https://www.barebones.com — a 34-year-old text editor that “(still) doesn’t suck.” The site is clearly written by a cowboy indie developer who doesn’t care what the cool kids in the valley think.

https://news.ycombinator.com/ — it’s amazing how much use they’ve gotten out of this simple hyperlink + feed concept. Their commitment to the chronological feed is what keeps me coming back.

https://www.space150.com — an agency that proves that simplicity doesn’t need to be old-fashioned. A lot is going on, but it’s controlled and well-structured. They redo their website very frequently, so revisit this site in a few months for another variation of elegant simplicity.

Whenever I’m tempted to restyle a landing page (again), I revisit these. Before long, I usually conclude, “Ya know what, I kinda like it how it is.”

More

Rich Siegel interview (substack)

Rich Siegel explains how he works (usethis.com)

This idea originates from Lambda calculus, a mathematical system developed by Alonzo Church in the 1930s. Its impact didn’t extend beyond formal math until the late 1950s, when John McCarthy created Lisp, which treated functions as first-class objects. Soon after, linguistics applied lambda calculus to the semantics of natural language.

Now that functions are inextricable in programming, we rarely have to consider their origins. But think about it, whatever programming language you use treats functions as entities with the same status as other data types like integers, strings, or arrays. Treating functions as first-class citizens is what allows us to

• Assign them to variables

• Pass them as arguments

• Return other functions (func-ception)

• Store them in objects, lists, or tables

Without the ability to treat functions as data, we couldn’t have:

• Higher-order functions (.map, .filter, .reduce)

• Callbacks that run when an event (like a button click) occurs

• Asynchronous programming (async/await)

• Closures

• TypeScript

Programming at its best is building complex systems by combining simpler building blocks in a disciplined manner. It’s easy to glorify the builder or complain about the system’s complexity. But let’s also appreciate the simple building blocks that our predecessors gave us. Without them, modern software would be unthinkable.

BTW - Isn’t it amazing that we’re still coming up with new math concepts? Your great-grandpa lived in a world that couldn’t reason about functions and integers at the same level of abstraction.

AFK primitives

If “treat functions as data” is a simple building block that empowers programmers to tackle computer problems, what are some simple ideas that could empower programmers to tackle problems AFK?

Here are a few.

Move in a way that you enjoy. Box, run, lift, power walk, swim — as long as you’re moving, you’ll avoid the traps of this sedentary profession. Hunched posture, processed food, sleepless nights, chronic distraction, and social anxiety are enemies of movement.

Do something you believe in. Main characters have points of view and fight for them. NPCs believe whatever they’re told and accept submissive positions. Changing your character doesn’t require you to quit, relocate, buzz your head, or get another degree, though. You already possess one of the highest-leverage skills available (building robots), anyway. If you apply your skills to your beliefs, your aura will grow. As your aura grows, so does your ability to handle hardship.

Think with simple tools. You don’t need an LLM, a second brain, or Spotify Premium to clarify your thinking. A pocket notebook is enough. Take a walk to organize your thoughts, then write down the important stuff. The more you outsource your higher-order thinking to artificial tools, the less competitive your ideas. If you combine your unique perspective, experiences, and voice, then your thoughts become more singular. Thinking differently is differentiating in a world where everyone is asking the same two apps the same questions.

Got a building block you swear by? Reply here to LMK.

More

Lambda Calculus (wikipedia.org)

Ergo: a case study in approachable invention (keepsoftwaresimple.com)

minimal bullet journal setup guide (youtube.com)

Brian Beckman: Don’t fear the Monad (youtube.com)

The first lecture of my college English class taught me to survive as a software engineer.

The professor asked everyone to open their notebook and write down the following class guidelines:

1. Bring books to class

2. Late work is not accepted

3. Submit hard copies only (no emails)

4. If you come late, don’t come

5. Hold your pee

6. One person talks at a time

7. No neighbor idle talk

8. Don’t sleep

9. Take notes during movies

10. No cell phones

11. No texting

12. No computers

13. Sign in

14. No food (drinks OK)

15. Paper grades are based on 70% content, 30% editing

16. Grades will be returned promptly

17. Discussions & lectures are mandatory

18. No hoodies (see #8)

19. No extra credit

20. No absences

21. No cheating

My high school teachers warned us that college would be different. I assumed they were exaggerating to scare us into being quiet. I quickly realized they were just telling the truth. I glanced across the room and saw dozens of other wet-behind-the-ear students having the same realization.

Some scoffed indignantly, as if the professor’s standard was unreasonable.

Some looked defeated, as if they had already received a C-.

But a few lit up.

These were the future A-students. They came to college hungry for knowledge. They were excited that an authority figure challenged them, rather than admired their intelligence. They appreciated that he was also holding himself to a high standard (#15, #16).

The high standard offended the C students and inspired the A students.

You probably know where I’m going with this:

This phenomenon doesn’t stop after college.

Show me an engineer who reads a job description and complains, and I’ll show you a C-player.

High expectations threaten these people because they expect to coast without consequence.

The same expectations excite the A-players because they recognize that they need to get to improve.

What to do with this info day-to-day?

Depends what kind of student you want to be.

Are you good with modest improvements in skill, income, and influence? Do competition, candor, and performance metrics drain you? Do you need work-life balance? Then you can expect to get a C or B.

All good, I won’t shame you or try to convince you to go for an A. Just don’t fool yourself.

If you aspire for As, on the other hand, don’t let the C players bring you down. You might be in the same company as them, but the rules are different. They just need to show up and do the minimum. You need to do the most.

Practically, this means doing the functions listed on your job description and then doing part of another person’s job.

^ That seems crazy, but it works. Instead of trying to explain it here, I’ll just point you to my deep dive on YouTube.

I was hesitant to share this harsh message until I realized that silence comes at the expense of the aspiring A-Players. Every scoff from someone who doesn’t aspire towards greatness has the potential to discourage someone who does.

We need more A-Players in this field, especially now.

If you’re on the fence, it might help to know this last detail:

Although I was initially terrified by my English professor’s expectations, I decided to give it my all anyway. It was hard work, but I got an A. But this is the best part: We stayed in touch after the class ended. We initially chatted about books, then music, then life. It’s been fourteen years since that first lecture, and I’m so proud to say that my professor is now my best friend.

Takeaway:

A-Players attract one another.

If you want to surround yourself with exceptional people, you need to become one yourself.

While prepping to launch Compass Calendar v1.0.0 this week, I dug up my early designs from 2021.

(Yes, it took 5 years.)

(Yes, that’s insane.)

I couldn’t help but chuckle at what I saw.

I envisioned a superapp that’d support a plethora of data types: events, tasks, habits, reminders, tags, and routines. I wanted it to be as powerful as Notion, but less heavy-handed.

So I started coding.

Then I made every first-time founder mistake in the book:

• Stuffing it w/ features

• Ignoring feedback

• Using Electron

• Chasing VCs

• Wearing fleece vests

I built a bloated app that no one used.

Eventually, I looked in the digital mirror and thought:

“I gotta lose some weight.”

I spent the last seven months deleting, consolidating, uninstalling, and refining.

As a result, v1 does a lot less than v0:

• It only has events and tasks

• It only works on the web (not desktop, not mobile)

• It only syncs w/ GCal (not Outlook, not iCal)

• It only has two views (initially it had five)

But what it does, it does well.

In 2021, shipping something so lean would’ve embarrassed me.

In 2026, the product’s minimalism is what makes me proud.

That’s because along the way, I learned a priceless lesson:

Simple !== easy

Entering B&W gym felt like a Teenage Mutant Ninja Turtle scene. I descended hesitantly to the basement of an unmarked Chicago building. The air was heavy, sweaty. The pipes were exposed, the ceiling low. At the entrance was a Master Splinter-esce old man staring at a spreadsheet running Windows 7.

Instead of greeting me with a fake smile, he stared at me.

After a few seconds of silent eye contact, I told him I wanted to buy a month pass. He said it was $65, cash or Zelle. I told him I don’t have Zelle, and that I only had $46 cash on me. He said, “Fine, you can pay the rest next time.”

I handed the money over and waited, expecting him to take my picture on a USB webcam, give me a tour, talk about the personal training packages, or hand me a long waiver to sign.

Instead, he stared at me.

After a few seconds of eye contact, I asked, “Anything I need before I start?”

He said, “Just common sense.”

I worked out with the old yet functional equipment that commercial gyms avoid — metal plates are loud, and unbranded cable machines from the 90s aren’t as aesthetic as monotone NordicTracks.

On my way out, the man handed me a laminated card:

Name: Tyler Dane
Exp: 7/7/2026
N/R: N

He told me to hang it up on the sign-in board next time.

The experience was void of the pageantry and fake salesmanship that I had gotten so used to at commercial gyms. Master Splinter didn’t care about hitting a quota or guilting me into a customer success survey. He didn’t want my email for a funnel. He didn’t wanna hear about my weekend plans. He didn’t need me to download an app, create a profile, share my checking account routing number, or consent to a $120 initiation fee.

In fact, it seemed like B&W didn’t need anything from me at all.

Just hang up my card. Don’t break things or get hurt. Then leave.

After some research, I learned that B&W was founded in 1978 as one of the original powerlifting gyms. The guy who checked me in wasn’t Master Splinter. It was the owner, world champion bench presser Dennis Brady.

Things started to make sense.

This gym wasn’t built to optimize revenue or expand a global franchise. It was built to give lifters a place to lift.

Operations are so simple because everything except lifting is a distraction.

A gym built by lifters for lifters.

Experiencing that purity was more motivating than any polished commercial gym.

It’s gotten me thinking:

What would B&W look like in the digital world?

What would an app feel like if its developers were also its users?

How would a tech company feel different if it planned to operate for half a century instead of half a decade?

I’m still figuring out the answers, but I know one thing:

» Things would be simple.

Or just keep skimming this =]

These examples follow the playbook that Elon runs across his companies, officially called “The Algorithm”:

1. Question every requirement

2. Delete as many as possible

3. Simplify

4. Go faster

5. Automate

Last issue explained how Elon resorted to this playbook to solve bottlenecks at PayPal, Starlink, and SolarCity.

The same framework also works proactively, as we see with Tesla’s Optimus robot.

The one requirement Elon mandated was that it should resemble a human. But the designers, already students of The Algorithm, knew to eliminate. When designing the hand, they initially tried to omit the pinky, which seemed like overkill. They quickly realized that it made the robot too creepy, so they added it back.

This satisfied Elon’s corollary that 10% of eliminated parts should be added back (otherwise you’re not cutting out enough).

Estimating costs early also helped the team surface unnecessary complexity. When they reported that the actuators for the wrist would balloon costs by 54%, Elon pushed back hard:

"This is a shitty design. Use the damn lift gate actuators from our cars, which we know how to make cheaply.”

They eventually settled on a more refined design that included two finger joints (not like our three), two degrees of wrist rotation (unlike our three), and cheaper parts.

Takeaway for engineers

It’s never too early to push back against complexity. Although many of the Optimus meetings indulged in distant-future planning scenarios (like robots on Mars), Elon used cost to bring things back to earth.

We engineers usually don’t have as much visibility into costs, but we know how long things take. So when a PM proposes something complicated to placate a demanding client, it’s on us to push back about how much time that extra feature will take. Even better: explain how the real solution to going faster is not to add more parts, but to remove them and prevent more from being added so carelessly.

More

Elon keeps it simple (fullstack.zip)

Elon Musk, Walter Isaacson (amazon.com)

How Elon Works, Founders Podcast (youtube.com)

Or just keep reading =]

How Elon protects simplicity

Elon created “The Algorithm” as a playbook to accomplish great things quickly at low cost. It goes like this:

1. Question every requirement. Requirements are recommendations. The only immutable ones were those decreed by physics.

2. Delete any part or process you can. You may have to add them back later. In fact, if you don’t add back at least 10% of them, then you didn’t delete enough.

3. Simplify and optimize.

4. Accelerate cycle time. In other words, “Go faster.”

5. Automate.

Remove, simplify what remains, then automate the process. It seems trite in the abstract, but a few examples will show how radically committed Elon is to this philosophy in practice.

During the early Paypal days, opening a financial account required the user to fill out long forms and hand over their SSN and address. Elon rewrote his site to get the fewest number of keystrokes to open an account by eliminating those forms and even the requirement to have a username (using email as the userid).

When Starlink’s satellites became too bulky and expensive to manufacture, Elon fired the leaders and led marathon meetings to challenge every little requirement. A rat’s nest of parts was turned into a simple flat satellite, and costs decreased by orders of magnitude.

Life got way easier because we culled those parts. I was too chicken to propose that, but Elon made us try it.
— Mark Juncosa, Starlink

When SolarCity’s panels lagged, Elon fired the leaders and eliminated the requirement that they must work around every vent and chimney pipe. Instead, they decided to shear them off and put the panels on top. The 240 roof parts were halved. The website was simplified to offer just three roofs: small, medium, and large.

When SpaceX’s Raptor engine proved incapable of a Mars mission, Elon instructed his team to focus on a lean design, one reminiscent of a gnarly post-skinned cat. He suggested some extreme ideas, like deleting the whole gas manifold and booster skirt. Then he emphasized his commitment to leanness with a flurry of emails.

We are on a deletion *rampage*!!

Nothing is sacred. Any remotely questionable tubes, sensors, manifolds, etc. will be deleted tonight. Please go ultra-hardcore on deletion and simpli cation.

Takeaways for software engineers

There’s a clear pattern throughout the book: When Elon sees a bottleneck, he removes rather than adds. Instead of adding more employees and materials, he fires people and removes parts.

This instinct is worth appreciating for us engineers, who have gotten used to adding with impunity. When a senior engineer imports a library, adds a framework, and integrates with a third-party, no one blinks an eye. Code is cheap, and it’s only getting cheaper.

But just because adding lines of code is easier than adding rocket ship parts doesn’t mean it’s free. There is a cost to every abstraction. For us, that cost is time. It takes time to dig through convoluted business logic, to wait for long CI runs to finish, and to tiptoe around a brittle part of the codebase.

When things become bloated, slow, or pricey, we should resist the urge to optimize and instead question whether we need the thing in the first place.

Removing abstractions, imports, and requirements will poke some egos, but so will becoming a team that’s incapable of shipping anything good.

More

Elon Musk, Walter Isaacson (amazon.com)

How Elon Works, Founders Podcast (youtube.com)

What people don’t know is that his books are written on a DOS machine running WordStar 4.0, a VBA word processor that dominated in the 80s thanks to its portability and WYSIWYG interface. Slow revisions, kludgey code, and corporate drama slowed progress long enough for Word to dethrone WordStar as the corporate standard. After a failed merger and relaunch, WordStar was officially abandoned in 1992.

So why does he still use it thirty years later?

Because it works.

It does everything I want a word processing program to do, and it doesn’t do anything else. I don’t want any help. I hate some of these modern systems where you type a lowercase letter and it becomes a capital. I don’t want a capital. If I wanted a capital, I would’ve typed a capital. I know how to work the shift key!
— GRRM.

Lessons

George’s preference for less is refreshing in an era obsessed with more.

Young carpenters might lose some sleep researching the benefits of Milwaukee vs DeWalt tools, while mechanics compare Gearwrench to Ryobi. But then they wake up, buy a set, and use those tools until they die.

We digital craftsmen, on the other hand, will try five IDEs and LLMs in a week. It’s easy to rationalize this schizophrenic adoption as an attempt to keep our skills sharp. But that mindset reveals a mistaken understanding of our role in the world.

It’s not about the tools, it’s about what you create with them.

Carpenters translate ideas into houses. They can do that with a nail and hammer, or a cordless track saw with an attached vacuum bag.

Writers translate ideas into words. They can do that with a DOS machine running WordStar 4.0, a phone with the Notes app, or pen and paper.

Coders translate ideas into code. They can do that with an agent window, vi and a keyboard, or ChatGPT and their voice.

Examples

Pieter Levels continued to write plain HTML, CSS, SQLite, and PHP in Sublime Text long after VS Code became the standard IDE. His friends made fun of him for his outdated tools. His followers pointed out the superiority of TypeScript and Docker. Yet he focused on his users and products long enough to generate $3M ARR with an ancient stack.

René Rebe codes in a single terminal with vi and basic motions. That elementary setup helped him focus on the code long enough to write a USB driver from scratch in three hours.

$LOUD_ENGINEER_ON_X uses NeoVim, configured through LazyVim, with a fully customized setup that auto-provisions via dotfiles managed by Chezmoi, stored in a private self-hosted Forgejo Git server running on a home Kubernetes cluster. His workflow is so “optimal” that he sells a course to young engineers on how to replicate it. (He hasn’t shipped anything helpful for normal people in years.)

Which type of engineer do you want to be?

If you want to be like the last engineer, then keep jumping on whatever new VC-backed tool shows up on your feed this week.

If you want to be like the first two, your path is much simpler:

1. Use simple tools that do a few things well. Really, just pick any IDE, calendar, task app, and OS and don’t overthink it.

2. Keep using that tool until it breaks or your craft suffers.

“BuT tEcH mOvEs So FaSt. I nEeD to sTaY rElEvAnT!”

Yes, occasionally a truly innovative tool appears that is so superior it’d be questionable to resist it (think: computer vs. typewriter). Between those paradigm shifts, a constant stream of “new” tools appears, each overhyping its benefits, downplaying its costs, and distracting you from your craft.

You’ll know when a paradigm shift is happening, and you’ll have plenty of time to transition. You’re not jeopardizing your career by moving to the right of the adoption curve.

The real risk is maintaining a greater allegiance to novelty than to your craft.

When GRRM’s old computer finally died, he had his assistant build a state-of-the-art computer for him….so that he could run DOS and WordStar 4.0.

WordStar shipped seven versions after 4.0. Instead of using this computer upgrade as an opportunity to try the latest version from 1994, he stuck with the 1987 program that he already mastered.

One of the most successful living writers demands simplicity. He wants his tool to do a few things well and let him handle the rest.

Let’s make George proud.

Close social media.

Open whatever IDE you’re already used to.

And get to work.

More

Interview with James Corey (lightspeedmagazine) | GRRM’s assistant

The best engineer doesn’t have the best setup (fullstack.zip)

A Tour of Word Star 4.0 (youtube)

WordStar (wikipedia)

The simplest $30k playbook

It was called “Bootstrapping Your E-Commerce Empire Side Hustle With No Money,” led by Jonathan Spaulding. He walked us through how to find a niche, set up a no-frills store, and ship, all without spending a nickel.

There were some pragmatic cost-saving tactics, like 3D-printing custom products and offering only small items to minimize shipping. What I enjoyed the most, however, was how simple he kept his operations.

His go-to-market involved walking around his house with a cardboard box, adding things that he didn’t need, and listing them on eBay that day.

For market research, he asks coworkers what small items they recently bought and makes them for less with his 3D printer.

To fulfill orders, he gets a bundle of USPS boxes and puts them in his home mailbox.

For support, he responds through the eBay mobile app during downtime.

However indignant the e-com gurus may feel about these elementary strategies, they work for him. This side hustle nets Jonathan $30k of yearly profit.

That headline isn’t going to make him HackerNews famous. But so what? That’s a year’s tuition. Runway for a startup idea. $66k in 10 years at 8% growth. An epic vacation. Enough Claude credits to create a custom C compiler. It also fits his lifestyle by allowing him to work from his phone and stay home with his family.

Why simplicity sells

Our feeds are so good at convincing us that we need more information before we’re ready to do things in the world. We need to watch the next video, finish the course, or get a few more years of experience before starting something new.

People like Jonathan prove them wrong.

You can just do things.

Yes, right now.

Really, it’s that simple.

Not easy, but simple.

This is especially true for engineers, who have more agency than ever. We don’t need to learn a new framework, refactor the API (again), or wait around for a job offer.

We just need to walk around our metaphorical house with our metaphorical cardboard box and sell things to people who want to buy.

There are two ways to be loved as a software engineer:

1. Solve the most complex problems so others don’t have to

2. Make complex problems simple enough for regular engineers to solve themselves

The first path is for master craftsmen maxxing out their engineering skill. The second is for those who enjoy teaching as much as coding.

Let’s look at a few examples of the second type of person.

Jeff Delaney & YouTube

Jeff Delaney is the man behind the Fireship, a YouTube channel for devs with over 4M subscribers. Although the videos are well-produced and sprinkled with the dry jokes devs enjoy, there is a deeper reason why developers love the channel: It makes them feel smart, quickly.

After watching a regular technical video, I often feel even more overwhelmed than when I started the video 20 minutes earlier. Jeff’s videos, on the other hand, are so straightforward and down-to-earth that I actually understand the core idea. His flagship 100 Seconds of Code series, for example, makes CS topics like Big-O notation and GraphQL feel refreshingly approachable.

Jeff probably isn’t the best engineer, nor does he try to be. Instead, he combines his “good enough” engineering with a world-class ability to cut out complexity.

I always ask myself, ‘How much can I cut out of this video and still teach the concept effectively?’

I try to distill the concepts into a very potent shot of whiskey.

— Jeff Delaney, creator of Fireship

Rich Hickey & Clojure

Rich is a great engineer — he created the Clojure language after all. Instead of trying to become an even better engineer for its own sake, though, he spends a lot of time teaching others. During the first few years after Clojure’s launch, Rich went on a conference tour, spreading the good word about the language. In his classic Simple Made Easy talk, he defined the problem of complexity so well that a generation of programmers started valuing simplicity.

Rob & CS

I felt imposter syndrome during my first two years as a junior engineer. During that time, our lead engineer, Rob, gave lunch talks about engineering. He’d whiteboard draw simple diagrams about the basics of computing: transistors, data structures, the difference between OOP and functional languages. Every time I’d walk back to my desk with a lil’ pep in my step, because for just a few minutes it felt like I understood what was going on and that I belonged. That’s why everyone loved Rob.

If you’re the type of engineer who wants to balance both hard and soft skills, consider teaching your peers. We reward those who make things simple: they make the world less scary, which makes us feel more capable. Whether in a PR review or a big conference presentation, the most popular message will be the one that shows the audience that they have more agency than they realized.

You’re a non-technical founder selecting between two Founding Engineer candidates. This hire will be responsible for creating your MVP, scaling the engineering team, and solving the hardest technical problems along the way. They’ll set the bar for engineering excellence, and everyone will try to mimic how this person works and thinks.

You shadow both candidates for a day while they work on a passion project. Although you won’t understand the details, you’re hoping to observe their workflow and the tools they use, since they’ll likely set something similar up for you.

Engineer 1

This engineer runs Fedora on a Framework laptop, with Sway as his tiling window manager, but tmux layered on top as a second window manager inside the terminal. His editor is Neovim, configured through LazyVim, with a fully customized setup that auto-provisions via dotfiles managed by Chezmoi, stored in a private self-hosted Forgejo Git server running on a home Kubernetes cluster. All development happens inside dev containers via DevPod, so there’s always a container runtime running.

Every tool is picked to keep workflows in the terminal and on his hardware. He uses w3m as a terminal browser to avoid trackers. He uses Aerc for email, an open-source terminal client. He also operates his own databases. Claude is kept in a container so Anthropic can’t see his notes or dotfiles.

His setup lets him sit down at any machine and be fully operational in minutes. As the owner of a DevOps education business, his workflow also demonstrates to prospects what’s possible if they commit to privacy and the terminal.

Engineer 2

This engineer works in a single, full-screened terminal. He uses vi with only basic motions and no syntax highlighting. His “workflow” involves changing the default font to Comic Sans.

He’s decided that he needs a USB driver for his kernel. He starts by googling “apple xserve frontpanel usb driver github,” scans the repo, and concludes, “Ja, this is super simple” (German accent).

He starts by copying and pasting Linux kernel code, mumbling in C, and sipping espresso. Thirty minutes in, he leans over to boot up the physical server next to his desk, which hums loudly for the rest of the session. Then he starts writing his own code. After 2.5 hours, he calmly reports back, “So, ja. It works. The future is now.”

My pick

I’m going with Engineer 2. He gets it. It’s not about fancy tools or impressive workflows that require a paid course to understand. It’s about shipping software. If this guy is comfortable raw dogging C in vi without any AI, I’m comfortable trusting him with the codebase.

The people on YouTube agree:

“I trust this man with my life.”

“This guy is not getting replaced by AI.”

“Writing code without syntax highlighting is demon level.”

“This is engineering.”

“Every time he says ‘Yes, of course,’ I just nod along. ‘Yes, of course.’”

To be fair, I straw-maned Engineer 1 big time. He’s a DevOps pro with serious credentials. Comparing his workstation demo to a C programmer’s live stream is apples to oranges. But by Engineer 1’s own admission, his system is elaborate. After all, it took him 70 minutes to explain how it all works. There’s a coherent philosophy of protecting privacy and flow state underneath it all…but it’s still a lot.

Solving meaningful problems for customers will bring plenty of necessary complexity. I want to work with people who are content to keep everything else simple.

Who you picking? Reply to LMK.

More

Watch Linux kernel developer write a USB driver from scratch in just 3h for Apple Xserve front-panel (youtube)

My Entire Neovim + Tmux + AI Workflow (2026 Update) (youtube)

Listen to any great engineer long enough, and they’ll eventually mention the idea of “simplicity.”
They’ll say things like, “Keep it simple.”
They’ll block your PR because it adds a little dependency.
They’ll yap about how we sent a man to the moon with 64kb of code.

Why do they care so much about this idea?

They care because they’ve felt the pain of complexity.
One day, they decided they were fed up with all the BS.
They just want to build things that work and tune out the noise.

I considered expanding this post by curating data and sharing my anecdotes from building web apps over the last decade. But sometimes it’s better to stay quiet and let the real pros speak. So here’s what the truly great programmers think about simplicity.

The web is basically a very simple idea. Very simple.
— Sir Tim Berners-Lee, inventor of the internet

Keep it simple. When in doubt during design, choose the simplest solution.
— Brian Carpenter, early CERN and IBM, CS PhD

We don’t need gigabytes of code. If we can write small programs, we have a chance at understanding them.
— Joe Armstrong, Erlang inventor, CS PhD

C is a very simple language. It’s one of the reasons I enjoy it.
— Linus Torvalds, created Linux kernel & git

An idiot admires complexity, a genius admires simplicity
— Terry Davis, created TempleOS

More

Architectural Principles of the Internet (1958)

TempleOS | Down the Rabbit Hole (2019)

Making reliable distributed systems in the presence of software errors (2003)

Devs love speed, which is why we’re obsessed with benchmarks and Rust. But speed is not just about acceleration; it’s also about mass.

So what’s the heaviest part of our codebase?

Dependencies.

In other words, other people’s code that we rely on to make our code work. GitLab’s 2024 survey of 5,000 DevSecOps pros claims that over 25% of the code devs work on is from open-source. Those guys are either working on CLIs or lying. My calendar app’s codebase has 10 million lines. I only wrote 116,351 lines — just 1.2% of the product. The other 98.8%? Other people’s code.

These numbers are insane, but not anomalous. Web apps are especially bloated these days. This is why we should spend less time looking at the speedometer and more time looking at the scale.

Dependencies are weight

Every dependency adds weight. The more you carry, the more every step costs, and the slower you move. Using minimal dependencies is like traveling internationally with a backpack. You might be going to the same destination as your buddy who brought two suitcases, but you’ll have vastly different experiences.

Let’s start with the heavy traveler, the one who has a “checked” codebase. What is his life like?

Checked codebases

The repo started small and grew quickly. Each dependency felt like a good idea at the time. Of course, you need an HTTP client (even though it comes with a bulky logger). Of course you need that component library with strong opinions about theming (even though you’ll only use five of its components). Of course you should start with $FRAMEWORK_THAT_EVERYONE_IS_USING.

He started with a lot, added more along the way, and never stopped. The PMs were eager to add features, and no one slowed the sprawl.

Now the builds take forever, no one understands why half the packages are there, but they’re all too afraid to do anything about it. So instead of simplifying globally, everyone optimizes locally. He’s greasing the wheels of a 50-lb suitcase instead of taking out the 10-lb boots. He optimizes, but he’s still big and slow.

Traveling with a checked codebase is exhausting. It takes a lot of planning to do a little movement. Each implementation step is also laborious, as he has to check so many surfaces for downstream bugs. He’s forced to bring a month’s worth of clothes for a short weekend getaway hotfix. By the end of the trip, he’s more exhausted than when he left.

Carry-on codebases

The minimalist is initially scoffed at as a simpleton, an irresponsible kid unprepared for the prod life. He sticks to what works, fights complexity vigorously, and has enough clout to be trusted. As a result, his dependency tree is minimal. Everyone knows what every package does. Sure, some teammates grumble about how a modern tool would be faster. But, on the whole, things are working. The builds are fast enough, newcomers can understand the code in days instead of weeks, and things get shipped.

Traveling with a carry-on codebase is chill. A POC gets demo’d. Builds pass. Merged. Done. There are fewer hotfixes, patches, docs, and meetings. The trips to Featureville actually feel energizing, and the team looks forward to the next experiment.

When the requirements change, it’s easy to recalibrate and move forward. Coding here feels like freedom. Not from bugs or feature creep, but from the weight that used to make overcoming those challenges so draining.

The reality of travel

Traveling light has become even more important recently, because travel itself has remained complex. While the vibe coding narrative promises to collapse the SDL into a one-shot prompt, we know that there are still many steps to shipping real products.

Pull → install deps → run tests → wait for CI → deploy → retest → get design feedback → get PR feedback → repeat → deploy to prod → fix bugs → write docs.

The journey is long. At every stage, a heavier dependency graph adds time. Moreover, the dependencies themselves require attention.

We still need to upgrade them. This is like replacing a backpack with a hole at the bottom with a new one.

We’ll need to swap heavy deps for alternatives. This is like swapping a heavy cotton sweater with a light dry-fit one.

We’ll still need to remove third-party libs with built-ins. This is like leaving your glass tupperware at home when you learn the hotel provides some.

Like it or not, dealing with dependencies is still part of our lives, which means it’s still helpful to learn how to pack lightly.

A small dependency graph will not make your product automatically great. But it will make the product easier to build, easier to understand, easier to debug, and easier to adapt when reality changes.

A light traveler is a fast traveler.

Story from the road

I fly with this backpack instead of those rolly carry-ons that real adults use. It fits overhead and underneath. It lets me take the stairs at the hotel when the elevator line is long. It helps me blend in at a coffee shop. When the ski lifts shut down, it allowed me to haul my gear to the top for one last run. My fancy shoes don’t fit, which means I lose some fashion points. But I gain so much speed and lightness. Once you feel that freedom, it’s hard to go back.

More

On the Relationship between Software Complexity and Maintenance Costs (2014).

Software complexity and maintenance costs (1993) | Analyzes Cobol maintenance projects in a large commercial bank.

Software Dependencies, Work Dependencies, and Their Impact on Failures (2008) | How dependency measures relate to defects.

DevSecOps Report: Application security in the digital age (2024) | GitLab’s survey

Do you think traveling light is always better, or are there exceptions?

Anthropic accidentally leaked its Claude Code source code. Although the archived repo is easy to find, deeper analysis is not. The popular reactions are surface-level, while the technical reports read like a mindless doctor’s note written by Claude itself.

“It’s just a Bash wrapper.”

“Wait, that’s it? This is so hack-y.”

“There’s an undercover pet!”

“It’s a CLI with multiple layers of abstractions.”

I blame the lack of substance on the legal grey zone we’re in: linking the repo or sharing specifics would anger the copyright police. At least that’s what my $20/month lawyer/SWE tells me.

After reading through the repo, I nevertheless have to share this amazing fact:

Claude Code has its own skill for simplifying code (simplify.ts).

That’s not as flashy as those other headlines, but it’s still important.

Coding with Gemini, Grok, or Cursor can feel like a game of whack-a-mole. They’ll add the feature I asked for and pass the tests…but they also litter the code with unnecessary comments, dependencies, and abstractions. Claude’s submissions feel more elegant — as if it spent some extra time refining away the rough edges first.

Well, that’s exactly what they’re doing, and it’s all documented in simplify.ts. Instead of pointing you to that file, though, here is my own “simplify-code” SKILL.md, which is spiritually equivalent to Claude’s.

// Excerpt from my SKILL.md for simplifying code 
---
name: simplify-code
description: Simplifies code by minimizing complexity, eliminating duplication, and prioritizing legibility for contributors. Use when implementing features, fixing bugs, refactoring, or when the user asks to simplify, clean up, make DRY, reduce complexity, or improve maintainability.
---

# Simplify Code

Favor minimal, legible implementations. Fewer lines and clearer structure make code easier to understand and maintain.
...

You and I aren’t the only ones who recognize the importance of this simple engineering philosophy. Claude is used by a whopping 75% of the smallest companies (ie, the ones that are free to use whatever they want) and is already the overall market leader, despite being released only 11 months ago.

It seems we agree:

When it comes to code,

Less > more.

Simple > complex.

We’ve been willing to pay for simplicity with our wallets and our time all along. Now we finally know why.

A few bonus observations:

Mixed file names. You’ll see kebab-case, camel case, Pascal case, and lowercase all in the root directory alone.

A few massive files. The entry point is 4600+ lines long, for example.

Types, kinda. It’s 100% TypeScript, but they don’t rely on types very heavily. There are lots of optional properties, and types aren’t widely shared.

My instinct tells me these are less engineering conventions they settled on and more symptoms of an internal POC that rapidly evolved into a mainstream product.

What was your first reaction to the leaked code?

More

AI Tooling for Software Engineers in 2026 | Pragmatic Engineer | usage stats

The format

They’re system design case studies, featuring popular apps.

Part I: Architecture. The stack, protocols, and main players that the featured app relies on.

Part II: Feature Deep-Dive. How everything comes together in the app’s most interesting feature.

Part III: Context. Where these ideas come from, and what they mean for regular devs like you and me.

The backstory

I broke down a few apps on my personal channel in 2024, and engineers seemed to like them. I got comments like this one:

Big fan of this! Definitely wanna see more video breakdown apps! :)

Of course, I ignored that feedback and instead uploaded 100 unrelated videos. When those flopped, I finally thought, “Maybe I should just give my audience what they want.”

I created “Fullstack Engineering” to be the strictly business vehicle for this educational content.

You’re probably familiar with the Fireship channel (4.1M subs as of today). If those videos are espresso, Fullstack Engineering is pour-over. They’re longer in format, but richer in context.

My goal with this channel is to give you something to watch during your WFH Friday lunch that educates and inspires. If you go back to the IDE excited, that’s a win.

Here are the first four.

Reply to LMK what app you wanna see next.

Before coding agents, a PR went through more checkpoints. You’d suggest a design pattern in an RFC or an issue comment. Your teammate would advocate for a different pattern. You’d go back and forth on the idea before committing to a tradeoff. After a day of POCing the first approach, you realized there’s an easier way, so you’d update the RFC or have another conversation. Then you’d submit a draft PR. More feedback from teammates who skimmed it with fresh eyes. They asked for more tests and told you how you could ditch that new library for a built-in. More refinement. By the time you make the PR public and everyone approves, your code is 2X simpler than the first version.

Things are different now.

Instead of clarifying our thinking in an RFC or issue, we prompt and get a PR. An agent reviews the code and auto-fixes major bugs. Another writes the PR description.

The end.

Sure, there’s a little back-and-forth between you and the agent, but only enough to make the tests green. Even reading the code is starting to feel like an inconvenience.

Our velocity has skyrocketed, but so has the complexity of our codebases. Part of that complexity is inevitable. Yet more is a byproduct of accepting the agent’s defaults without scrutiny. The agent doesn’t want to waste tokens refining its already green solution, and we don’t want to waste time nitpicking. So extra libraries get added, nested if statements sneak in, and kludgey abstractions get overlooked.

Teams won’t care until their complexity debt starts to slow their velocity or introduce more bugs. At that point, it’ll be tempting to start from scratch with another prompt. But there might be a more pragmatic way out.

Solution: Simpler tools

Replace complex tools with simple tools. Keep the requirements and tests, but replace one heavy tool with a lighter one.

To make this practical, here are 40 swaps to consider, organized by domain.

Simpler Auth

1. Auth0 / Clerk → express-session + bcrypt + a users table. Don’t lock yourself into a vendor for a personal project.

2. OAuth → API keys. Trade the redirect dance with an API key in the header. Consider OAuth when your users can only auth with accounts they don’t control (rare).

3. Username / password → Magic link. No hashing, strength enforcement, or reset forms.

4. Per-route auth middleware → Single auth gateway. A single middleware that authenticates every request by default is easier than sprinkling requireAuth() on each route.

5. SSO → anything else. Add it when a paying customer asks for it.

6. JWT everywhere → Server sessions. Easier to revoke and doesn’t require rotation.

7. RBAC service → role column on a users table. Unless you’re an enterprise, WHERE role = ‘admin’ in your middleware is fine. Consider a better abstraction when you have 3+ distinct roles.

8. Third-party MFA service → TOTP + otplib. It’s an open spec, and otplib generates and validates codes in ~10 lines. There’s a maintenance burden, but it might be cheaper than locking yourself in too early.

9. Refresh token rotation → long-liven tokens + revocation list. If calls are inside your infra, you might not need to worry about refreshing yet.

10. passport.js → manual middleware. Passport adds 20+ files and a plugin ecosystem just to check a password and set a session. If you're not juggling multiple strategies, a verifyPassword function and a session check is 15 lines and nothing to maintain.

Simpler Storage

1. Redis queues → Postgres LISTEN/NOTIFY. Postgres has a built-in pub/sub mechanism. NOTIFY sends a message on a named channel; LISTEN opens a persistent connection that receives those messages in real time. You can store messages in a jobs table and tell workers to pick it up on NOTIFY. Or use a lib like pg-boss if you don’t wanna coordinate locks and retries yourself. This’ll last you until you get to a few hundred jobs / second.

2. Trendy DB → SQLite. A single file, zero config, and it handles tens of thousands of reads per second. Upgrade to Postgres when you need concurrent writes from multiple processes.

3. Time-series DB (InfluxDB) → Postgres timestamptz + indexes. For application metrics, user activity logs, or event streams at normal SaaS scale, a timestamptz column with a partial index covers the query patterns without running a second database.

4. Separate search service (Algolia, Elasticsearch) → Postgres full-text search.

5. ORMs (Prisma, Sequelize) → SQL + a query builder. OMRs abstract SQL until they don’t. If you’ll be writing raw queries anyway, a lightweight query builder can get the job done without hiding the DB from you.

6. MongoDB → Postgres JSONB. If you’re already on Postgres and don’t want to stress about schema design upfront, you can still use JSON for now without having to bring in another DB. IF your data is document-shaped AND you’re confident you’ll hit scale quickly, then ignore.

7. Redis cache → Postgres Materialized View. Pre-compute the result and store it in a table. Great way to preserve speed for complex queries and avoid a cache. Must be OK with some data staleness.

   1. Use-case: daily sales dashboard.

   2. See: Choosing Between Postgres Materialized Views and Redis Application Caching (leapcell.io).

8. S3 → local filesystem. If you’re on a single VPS, you don’t need to manage another round-trip, IAM policy, and subscription. If GitLab could run its git commands on a shared NFS filesystem, you’re probably fine to store some files locally.

   1. GitLab Architecture (fullstack.zip)

9. Multiple databases → one Postgres schema per domain. Running separate databases for separate domains means cross-domain queries require application-level joins, separate connection pools, and separate migration pipelines. A Postgres schema per domain (users.accounts, billing.invoices) gives you logical separation with a single connection string.

10. Key-value store → single-table Postgres with a type column. Redis shines for ephemeral data — rate limiting, leaderboards, session tokens. For “store this thing and look it up by key” use cases in a persistent store, a Postgres table with (type, key, value, expires_at) is queryable, inspectable, and doesn’t require operating a second data store.

Simpler Infra

1. Fly.io / Railway → 1 VPS. SSH in, run your app with pm2, put Caddy in front. You own the machine, you understand the machine, and you're not beholden to a platform's pricing or uptime decisions.

2. k8s → systemd + reverse proxy. Automatic startup, dependency checking, and failure recovery.

   • How to run pods as systemd services with Podman | redhat.com

   • Replacing Kubernetes with Systemd | news.ycombinator.com.

3. Docker → Bash + pm2. Replace the whale with pm2 (for Node apps), and you’ll free up a ton of RAM, storage, dependencies, and time.

4. Terraform → Bash. For a personal project or small team with one VPS, a shell script that runs apt install, creates users, and drops config files is fine. Terraform is for provisioning lots of stuff across teams.

5. Secrets manager → Env files + chmod 600.

6. Staging environment → Feature flags. It doesn’t get more real than prod, not matter how much you dress up your staging env. How many of us are acting like we have an SLA with five 9s when we don’t even have 5 customers?

7. GitHub Actions → git hooks + deploy script. A post-receive git hook on your server that pulls and restarts is a 10-line bash script that deploys on git push.

8. Autoscaling → Vertical scaling. What happened first, you spent a week configuring autoscaling or 10 minutes doubling your VPS size?

9. Nginx + Certbot → Caddy. Auto-TLS, one config file. HTTPS in Nginx usually requires installing Certbot separately, configuring it, setting up a cron job for renewal, and debugging when it gets out of sync with your Nginx config. With Caddy, you just put your domain name in the Caddyfile — Caddy obtains and renews the certificate automatically, handling HTTP-to-HTTPS redirects, OCSP stapling, and multi-domain SANs with no additional configuration. The makers of Certbot even agree that this is a better solution for everyone.

   1. Should Caddy and Traefik Replace Certbot? | eff.org

10. Multi-region deployment → backups + a restore script. Small SaaS apps don’t need 99.99% uptime. A daily Postgres dump to S3 and a restore script that gets you back in 10 minutes is more than enough.

Simpler Libraries

1. ESLint + Prettier + Husky → biome. Biome replaces that entire stack with one tool — it’s 10–25x faster than ESLint and ships as a single binary instead of 127+ npm packages. Caveat: it doesn’t cover every ESLint plugin (e.g. eslint-plugin-jsx-a11y), so teams with heavy custom rule sets may not get a clean 1:1 swap.

2. Jest/Vitest + mocking libs → node:assert. Ideal for simple backend unit tests in pure Node.js environments where minimal dependencies are a priority (nodejs.org)

3. .env + dotenv library → Native --env-file flag. Since Node 20, you can load your env file natively.

4. node-config → env files. node-config is a popular library for managing environment-specific config (development.json, production.json, etc.). For most projects, a plain .env file per environment covers the same ground with zero deps.

5. uuid → crypto.randomUUID(). Why does the uuid package get 91 million downloads per week when crypto is native and 4x faster? I think it’s just a better name.

6. nodemon → node --watch. Unless you need granular ignore patterns, this simple flag is good for anyone on Node 18+.

7. axios → fetch. Works identically in browsers. Can upgrade if you need interceptors or fancy errors.

8. moment.js → Date or Temporal. Ditch the bulky libs for a lib that the JS ecosystem spent a decade pushing through. (You’ll need a polyfill until Safari gets its act together).

9. lodash → array methods. Lodash predates modern JS. _.map, _.filter, _.groupBy, _.flatten are all native today. Another example of muscle-memory keeping a heavy lib around.

10. express → v0: node:http, v1: hono. Node for simple internal services, hono if you need a router on the edge. 0 deps.

Conclusion

It’s easy for me to tell you to “just replace this whole part of your stack.” It’s hard to do this in a company, especially when you need to convince teammates along the way. After spending the last three months doing nothing but this type of cleanup in Compass Calendar, however, I can tell you it’s worth it. You’ll have fewer dependencies, fewer lines of code, and fewer headaches. You’ll start to understand the codebase again. Best of all, you’ll develop a deep conviction that’ll help you forever separate signal from noise:

It doesn’t have to be this complicated.

More

Simple is smart (fullstack.zip)

A Plea for Simplicity (schneier.com)

Choose Boring Technology (mcfunley.com)

77 Things to avoid in 2026: Developer edition (fullstack.zip)

The Law of Leaky Abstractions (joelonsoftware.com)

“I’m {FirstName}, and I’m a complex-oholic.”

Say it.

It’s OK, we’ve all been there — prioritizing our ego ahead of our users.

Deep down, we know we were overdoing it all along.

Not ready yet?

All good, it takes time. For now, skim this list and let yourself yearn for the days of yore, when life seemed so straightforward.

Simplify your system

1. Microservices → modular monolith. If you’re a small team, a monolith with clean module boundaries gives you the same separation of concerns without the network tax (Modular Monoliths).

2. Abstract base classes → plain functions + composition. If your class has one subclass, it probably shouldn’t be a class (The Composition Over Inheritance Principle).

3. Feature flag service → Env var + if statement. LaunchDarkly and friends are powerful when you have millions of users. You don’t, so if (process.env.IS_PREMIUM_USER === 'true') is fine (How To Build Feature Flags Like A Senior Dev In 20 Minutes).

4. Semantic versioning automation → git tag + a changelog entry. (Keep a Changelog)

5. GraphQL → REST + JSON. Do multiple clients need different shapes of the same data? If not, a REST API will be easier to build, cache, and debug (You probably don’t need GraphQL).

6. Event-driven everything → direct function calls. If two things always happen together, just call one from the other and save yourself the tracing scavenger hunt (Method Calls vs Event-Driven Architecture in a Modular Monolith API?).

7. API gateway → reverse proxy routes. Gateways come with rate limits, middleware, routing, and policies. Your existing proxy can do the essentials with a few config lines (Is an API Gateway a Reverse Proxy?).

8. Pub/sub → EventEmitter. Node’s built-in can handle internal pub/sub within a single process without a broker or network hop (Redis pub/ sub vs node event emitter).

9. Polyrepo → monorepo. This’ll cut down your CI configs, versions, PRs and repos. Go further by skipping Nx/Turborepo in favor of a simple Makefile (Understanding Monorepos).

10. Multi-tenancy → multiple single-tenants. Every unicorn engineer will proudly talk about their journey from single-tenant to multi-tenant. Every tech lead of a graveyard startup will reluctantly admit how they spent too much time optimizing instead of iterating (Choosing the right SaaS architecture: Multi-Tenant vs. Single-Tenant).

Did you reject these indignantly? Perhaps you bristled at the thought of a vet like you doing something so elementary.

Well, hopefully you’ll scale so quickly that you outgrow these script-kiddie tactics in a few months. None of the fancy things is wrong; they’re just wrong now, at this scale.

Just ship and help your users, then let the real problems tell you what to add back.

Complexity has its place.

Just not yet.