The Architecture of Procrastination

Picture a distributed system with health-checking protocols so aggressive that it spends 99.9% of its compute pinging itself. It validates configuration, renegotiates SSL certificates, optimizes internal routing tables. When an actual user request hits the load balancer, the system times out. Too busy getting ready to be ready.

That's the exact state of your side project.

We love to convince ourselves that configuring ESLint, debating type vs interface, or comparing Bun to Node.js counts as "work." It feels like work. It tires us out like work. But look at the logs: zero features shipped. Zero value delivered. You're stuck in a loop of motion instead of action, optimizing a server that serves nobody.

The recursion of preparation

The most dangerous trap for anyone with a System Thinking mindset is the belief that the system must be perfect before it can exist. We read blog posts about clean architecture (yes, the irony is not lost on me), watch tutorials on micro-frontends, and buy domain names.

Here's the pattern I've repeated more times than I want to admit:

1. You decide to build a blog.
2. You need a framework. Next.js.
3. Wait, you need a database. Postgres? Actually, Supabase.
4. Hold on, authentication. Better read the Auth.js docs for three hours.
5. Can't write code without a linter. Spend the evening making Prettier and ESLint cooperate.

By Sunday night you have a polished .eslintrc.json and an empty src folder. The play never started. You just set the stage.

This is what avoidance looks like in TypeScript

// The "I am preparing to work" pattern
 
interface IRepository<T> {
  find(id: string): Promise<T | null>;
  save(entity: T): Promise<void>;
}
 
// What if we change databases later? Better build a factory.
class UserRepositoryFactory {
  static create(type: 'postgres' | 'mongo'): IRepository<User> {
    if (type === 'postgres') {
       return new PostgresUserRepository();
    }
    throw new Error('Database not supported... yet.');
  }
}
 
// We haven't defined what a 'User' is,
// but we have a generic repository interface and a factory.
// This compiles. It does absolutely nothing useful.

This code is seductive. It looks professional. It respects SOLID principles. And it solves exactly zero problems.

The cure: do it badly

The only fix for analysis paralysis is to lower your standards for the initial commit. Doing the thing badly is better than preparing to do it perfectly. Your users don't care about your dependency injection container. They care if the button clicks.

In system terms, optimize for throughput over latency. Push data through the pipe, even if the pipe is leaky and held together with tape, just to see if the data is worth moving.

From analysis to execution

Task: send a welcome email to a user.

The architect's approach (blocking)

// Abstract Notification Strategy
interface NotificationStrategy {
  send(recipient: string, message: string): Promise<boolean>;
}
 
// Dependency Injection Container Setup...
// Mocking services for tests that don't exist...
// ... 4 hours later, no email sent.

The "just do it" approach (non-blocking)

async function main() {
  const userEmail = "test@example.com";
  
  console.log("Sending email to", userEmail);
  
  const response = await fetch("https://api.emailprovider.com/send", {
    method: "POST",
    body: JSON.stringify({ to: userEmail, msg: "Welcome!" })
  });
 
  if (response.ok) console.log("Done.");
}
 
main();

Ugly? Yes. But it validates three things that no amount of architecture can:

1. The API key works.
2. The network allows the connection.
3. The provider actually delivers the email.

Only execution proves these. Architecture assumes them.

The refactor (once it works)

After the ugly version runs, then apply structure. You're no longer designing in a vacuum. You're refactoring based on reality.

type EmailPayload = { to: string; subject: string; body: string };
 
const sendEmail = async (payload: EmailPayload) => {
  try {
    const res = await fetch(process.env.EMAIL_API_URL!, {
      method: 'POST',
      headers: { 'Authorization': `Bearer ${process.env.API_KEY}` },
      body: JSON.stringify(payload),
    });
    
    if (!res.ok) throw new Error(`Email failed: ${res.statusText}`);
    return true;
  } catch (error) {
    console.error("System Alert:", error);
    return false;
  }
};
 
sendEmail({ 
  to: "user@domain.com", 
  subject: "We actually shipped", 
  body: "It wasn't perfect, but it's done."
});

Why this works

Software development is a feedback loop: Idea -> Implementation -> Feedback -> Refinement. When you spend weeks in preparation, you're stretching the implementation step to infinity and delaying feedback. You're building on assumptions instead of data.

The bad version teaches you immediately that the API docs were wrong, or that the feature nobody asked for isn't fun to use. You save yourself from building a cathedral for a feature that should have been deleted.

Permission to be imperfect

There's a gentle irony in reading a blog post about how reading blog posts isn't working. I'm aware.

But if you take one thing from this: your code doesn't need to be a cathedral on day one. It can be a tent. Tents keep the rain off, they're portable, and they're fast to set up.

Stop researching the perfect state management library. (It's a global variable with extra steps anyway.)

Write the main function. Hardcode the variables. Ignore the linter warnings for an hour.

Doing the thing badly is the only path to doing it well.