A builder's routine (for now)

1. The honest version

Most "routine" posts on the internet describe a perfect day. Wake up at 5 AM. Meditate. Journal. Work out. Deep work for four hours. Healthy lunch. More deep work. Side project in the evening. Read for an hour. Sleep by 10 PM.

That is not our life. Our actual routine is messy, inconsistent, and full of days where absolutely nothing productive happens. We think it is more useful to describe the real version than the aspirational one, because the real version is the one that actually produces websites.

Here is the truth: Slop Brains is a side project. We have a day job. We have relationships, responsibilities, hobbies that have nothing to do with the internet, and a persistent inability to go to bed at a reasonable hour. The building happens in the gaps between everything else.

Some weeks, the gaps are wide. A quiet evening turns into two hours of focused CSS work. A lazy Saturday morning becomes a full project sprint. These are the good weeks. The projects move forward. Things get shipped.

Other weeks, the gaps do not exist. Work is demanding. Social obligations fill the evenings. The weather is too nice to sit at a computer. These weeks, the projects sit untouched. The ideas file grows longer, but nothing gets built. These weeks used to make us anxious. Now we accept them as part of the rhythm.

2. The day job

We work as a software engineer at a company that has nothing to do with small websites. The work is interesting, the team is good, and the paycheck is what makes Slop Brains possible. Without the financial stability of a day job, we could not afford to build things for free.

This is worth stating because the indie builder narrative often implies that you should quit your job, go full-time on your passion project, and live off ramen until it works. That is a valid path for some people. It is not our path. We like having a job. We like the structure it provides, the problems it presents, and the separation between "work we get paid for" and "work we do for love."

The day job helps the side projects

The skills transfer in both directions. At work, we learn about:

• Code review discipline. Having colleagues review our code at work has made us more careful with our side project code, even though nobody reviews it.
• Testing patterns. Work projects have test suites. Side projects do not (yet), but the habit of thinking about edge cases carries over.
• Performance at scale. Work projects serve millions of users. This gives us perspective on what "performance" means and, more importantly, what it does not mean for a side project with hundreds of visitors.
• Team communication. Writing clear commit messages, documentation, and code comments is a skill we practice at work and apply to side projects. The audience is different (colleagues vs. future self), but the skill is the same.

The day job competes with the side projects

There are days when work is mentally exhausting and the last thing we want to do is write more code. This is normal and expected. We do not force building on these days. The side projects are supposed to be fun. The moment they feel like a second job, something has gone wrong.

The trick is not to push through fatigue. It is to wait for energy. Energy comes in waves. Some evenings, we sit down at the laptop and the ideas flow. Other evenings, we sit down and stare at a blank screen. Learning to tell the difference and not fighting the low-energy evenings has been one of the most important lessons of the past three years.

3. A typical week

There is no typical week, but here is what an average one looks like when things are going well:

Monday through Friday: Day job, 9 to 6. After work, we decompress. Dinner. Sometimes a walk or a bike ride. Building happens between 8 PM and 10 PM on maybe two or three of these evenings. The sessions are short: 45 minutes to an hour and a half. Enough to make progress on one thing. Not enough to finish a project.

Saturday: This is the most productive day for side projects. If there are no plans, we often spend a three-to-four hour block in the morning building. This is when the big chunks of work happen: initial project scaffolding, full CSS passes, solving complex JavaScript problems. The morning is key. By afternoon, the energy has usually shifted toward other things.

Sunday: Rest day. We try not to build on Sundays. Sometimes we fail. But the intention is to have one full day with no code. Reading, cycling, cooking, seeing people. The break makes Monday evening more productive because the projects feel fresh again.

The bad weeks

In a bad week, zero building happens. Work is stressful. Evenings are full. The weekend has obligations. The laptop stays closed. This happens maybe once or twice a month.

We used to feel guilty about bad weeks. Now we do not. The projects are not going anywhere. The domains are paid up. The code does not expire. A week of rest does not undo months of progress. It just pauses it.

The guilt trap is real though, especially in an internet culture that celebrates hustle and constant productivity. If you are building side projects, you will have bad weeks. They are not failures. They are part of the sustainable pace that makes long-term building possible.

Tracking progress (barely)

We do not use a project management tool. We do not track hours. We do not set deadlines. The only tracking we do is the "Next:" note at the end of each session and a rough mental model of which projects are active.

This lack of tracking is deliberate. The moment side projects start feeling like work, with sprints, deadlines, and accountability metrics, the joy drains out of them. We build because we want to. The motivation comes from curiosity and the satisfaction of shipping, not from a Jira board.

4. Life outside the screen

This section is important because every "how I build" post focuses exclusively on the building. But the building is a small part of life, and the rest of life is what makes the building sustainable.

Cycling

We ride bikes. Road cycling, mostly. Sometimes gravel. Two to four rides per week, depending on weather and energy. The rides range from 30 minutes of easy spinning to three-hour weekend loops through the countryside.

Cycling has a direct positive effect on building. It clears the mind. Some of the best ideas for projects have come during rides, when the conscious mind is focused on the road and the subconscious is free to make connections. The idea for resign.fyi came during a ride. So did the concept for the "Find your side quest" quiz.

There is also a structural similarity between cycling and building that we find satisfying. Both reward consistency over intensity. Both produce compound results over time. Both feel pointless on any individual day but meaningful over months. One ride does not make you fit. One hour of coding does not make a website. But a year of each makes a noticeable difference.

Reading

We read physical books. Not because we are anti-digital (our entire creative output is digital), but because physical books provide a complete break from screens. After a day of staring at a monitor at work and then staring at a monitor for side projects, the last thing we want is another screen.

The reading is mostly non-fiction: essays, design books, cultural criticism, technology history. Occasionally a novel. We do not read to "learn things that apply to building." We read because we are curious. But inevitably, ideas from books seep into projects. A book about information architecture influenced how we structured protocols.page. An essay about internet culture sparked the idea for aislop.day.

Doing nothing

The most underrated activity for creative output is doing nothing. Sitting on a bench. Staring out a window. Walking without headphones. These moments of genuine boredom are when the brain makes unexpected connections. The constant stimulation of phones, podcasts, and social media fills every gap where an idea might have formed.

We are not good at doing nothing. We reach for the phone. We check feeds. We open browser tabs. But we are getting better at it, and we notice that the best ideas correlate with periods of low stimulation. This is not pseudoscience. It is just our observation from three years of building.

5. Energy management over time management

Every productivity system we have tried focuses on time. Block your calendar. Schedule deep work. Protect your mornings. Time-box your tasks. The assumption is that time is the scarce resource and managing it is the solution.

For side projects, this is wrong. Time is not the scarce resource. Energy is. We have plenty of evenings and weekends with available hours. What we do not always have is the mental energy to use them well.

The shift from time management to energy management changed everything. Instead of asking "When can I build?" we ask "When do I have energy to build?" The answers are different, and the second one produces better work.

High-energy tasks vs. low-energy tasks

Not all building tasks require the same level of energy. We have learned to match the task to the energy level:

• High energy: Solving complex layout problems. Writing JavaScript logic for search or filtering. Making design decisions about typography and spacing. Debugging issues that require creative thinking.
• Medium energy: Writing CSS for known patterns. Adding content to existing pages. Testing on different devices. Optimizing images.
• Low energy: Updating meta tags. Fixing typos. Renaming files. Committing and pushing code. Browsing domains for inspiration.

On a high-energy evening, we tackle the hard problems. On a low-energy evening, we do the maintenance tasks. Both move the project forward. The key insight is that low-energy evenings are not wasted if you have low-energy tasks ready. Keeping a list of "easy wins" means that even tired sessions produce progress.

Seasonal rhythms

Our building output follows seasonal patterns. Winter months are the most productive. The evenings are long, the weather discourages outdoor activities, and the cozy feeling of building something at a desk with a warm drink is genuine motivation.

Summer months are the least productive. The evenings are for being outside. Weekends are for cycling, swimming, and socializing. The laptop stays closed more often. We used to fight this pattern. Now we plan around it. Winter is for building. Summer is for living. The projects get finished eventually.

6. The ideas problem

We have too many ideas. This is not a humble brag. It is a genuine problem. The ideas file has over 60 entries. We can realistically build 3 to 4 projects per year. At this rate, we will never build everything in the file. New ideas arrive faster than old ones get built.

For a long time, this bothered us. The unbuilt ideas felt like obligations. The file felt like a backlog of failures. Every domain purchase that did not turn into a project felt like a mistake.

The reframe that helped: the ideas file is not a to-do list. It is a menu. We do not have to build everything on it. We get to choose from it. The unbuilt ideas are not failures. They are options. Some will get built. Most will not. The file is valuable as a source of possibilities, not as a checklist of commitments.

Saying no to good ideas

The hardest part of having many ideas is saying no to good ones. Not bad ideas. Good ideas. Ideas that would make useful websites, that have available domains, that we know we could build. But we cannot build them all, so we have to choose.

Our current decision framework for choosing what to build next:

1. Energy. Which idea excites us the most right now? Not which one is objectively best. Which one makes us want to open the laptop and start building? Energy is the most important factor because without it, the project will not get finished.
2. Scope. Can this be built in one to two weeks of evening/weekend sessions? If the scope is larger, can it be reduced to a shippable first version that fits that timeline? Projects that require more than two weeks tend to stall.
3. Usefulness. Would we use this ourselves? Not hypothetically. Would we actually open this website at least once a month? If yes, the project has a built-in quality check: we are our own first user.

The idea that scores highest on all three dimensions gets built next. Everything else stays in the file.

7. Sustainable pace

The internet celebrates speed. Ship fast. Move fast and break things. Launch in a weekend. Build in public. The implicit message is that if you are not shipping constantly, you are falling behind.

We reject this framing. Slop Brains is not a race. There is no competitor. There is no market to capture. There is no investor expecting growth. There is only us, building things we care about, at a pace we can sustain for decades.

Sustainable pace means different things at different times. Right now, it means 5 to 10 hours per week on side projects, with occasional weeks of zero. In the future, it might mean more or less. The pace is not fixed. It adjusts to life circumstances.

What sustainable pace looks like in practice

• No deadlines. Projects ship when they are ready. "Ready" means finished and polished, not "good enough for a launch date."
• No streaks. We do not maintain GitHub contribution streaks. We do not track consecutive days of building. Streaks create guilt on rest days, and rest days are essential.
• No public commitments. We do not announce projects before they are built. Announcements create expectations. Expectations create pressure. Pressure kills the fun.
• Permission to stop. If a project stops being fun and is not useful, we stop working on it. Sunk cost is real, but so is the opportunity cost of finishing something you no longer care about.

The long game

We think about Slop Brains on a ten-year timescale. Not what we can ship this month. What the collection will look like in ten years if we keep building at this pace.

At 3 to 4 projects per year for ten years, that is 30 to 40 websites. A substantial body of work. A meaningful contribution to the internet. All built in the evenings and weekends, without sacrificing the day job, relationships, health, or sanity.

That is the vision. Not a viral launch. Not a million users. Not an exit. Just a growing collection of small, useful, interesting websites, built by someone who cares about the internet and has the patience to keep going.

"The routine is not the point. The websites are the point. The routine is just what makes the websites possible."