Hey everyone, 

I've been asked a few times how I manage to get so many different projects and tools built so quickly. It’s a great question, and I was inspired to write about it after reading an excellent post by Evan Hahn, "[How I Build Software Quickly](https://evanhahn.com/how-i-build-software-quickly/)," which I highly recommend. Our philosophies are very similar.

![My original art idea looked way too sinister :)](https://files.peakd.com/file/peakd-hive/thecrazygm/AKbGiesjh62jdsBMYVvTjCarLQ9aHx5GJur6wC2theVLQdRE7H1X2HwJKK5S8fy.png)

For me, the "secret" to building quickly isn't about some magical coding skill. It comes down to a few core principles.

#### 1. Start with a Tiny, Working Version

This is the most important rule. The goal of day one is not to build the whole application; it's to build the absolute smallest possible thing that _works_. If I'm building a web app, that means getting a "Hello, World!" page live on a public URL. If it's a command-line tool, it's about getting it to print a single, correct piece of information.

This approach does two things:

- It solves the deployment and tooling problems first.
- It gives you an instant feedback loop.

This first, tiny version becomes the rock-solid foundation that I can iterate on.

#### 2. Build On Your Own Shoulders (Reuse Your Code)

I don't start from scratch every time. Over the years, I've built a personal ecosystem of libraries and scripts that I trust. When I start a new Hive project, I'm not reinventing the wheel on how to connect to the blockchain; I'm importing my own `hive-nectar` and `nectarengine` libraries.

By having these well-tested, reliable building blocks, I can focus immediately on the unique logic of the new application instead of solving the same foundational problems over and over again.

#### 3. Keep It Simple. No, Simpler Than That.

It's incredibly easy to over-engineer a solution. A huge part of moving quickly is aggressively cutting features and complexity. Does this tool _really_ need a database right now, or can it just read from a text file? Do I need a complex user account system, or can I just get the core feature working for anonymous users first?

I always start with the simplest possible implementation. You can always add complexity later if it's truly needed. More often than not, you'll find that the simple solution is good enough.

#### 4. The Tool Dictates the Needs

Finally, I let the tool itself tell me what it needs next. I don't sit down with a grand, ten-page design document. I build the core feature, use it myself, and then ask, "What is the most annoying thing about using this right now?" That annoyance becomes the very next feature I build. This iterative, feedback-driven process ensures I'm always working on the most important and impactful thing.

So, the secret to building quickly? It's about starting small, reusing what works, staying focused on the simplest path, and letting the project itself guide you.

As always,
Michael Garcia a.k.a. TheCrazyGM