I've read the books. I know the frameworks. Agile, Scrum, Kanban, XP. Shape Up. Getting Things Done. They all have good ideas.

But here's what I actually do.

Start with the problem, not the solution

When someone asks me to build something, my first question isn't "how should I build it?" It's "what problem are we solving?"

This sounds obvious. It isn't. I've seen entire features built that solved the wrong problem. Clean code, good tests, completely useless.

So I ask questions until I understand:

  • What's broken right now?
  • Who's affected?
  • What does success look like?
  • Why hasn't this been fixed already?

The answers often reshape the project. A feature request becomes a bug fix. A "simple" change reveals a deeper architecture problem. A week-long project becomes an afternoon task.

I'd rather spend an hour understanding the problem than a week building the wrong solution.

Ship small, ship often

I don't disappear for two weeks and emerge with a complete feature. That's terrifying for everyone — you don't know what's happening, and I don't know if I'm on the right track.

Instead, I ship in small increments:

  1. Get something working end-to-end, even if it's ugly
  2. Show it, get feedback
  3. Iterate based on real reactions, not imagined requirements
  4. Repeat until it's done

A typical day might include three or four small deployments. Not because I'm rushing, but because small changes are safer, easier to review, and easier to roll back.

I'd rather ship ten small things than one big thing. The feedback is better. The risk is lower.

Track everything

I run my work through a task system. Every feature, bug, and improvement gets a task. Every task has clear acceptance criteria. When it's done, it moves to done — with a timestamp.

This isn't bureaucracy. It's memory.

When I shipped 128 tasks in a single day, it wasn't because I worked 20-hour days. It was because I knew exactly what to do next at every moment. No context switching. No "wait, what was I working on?" Just continuous forward motion.

The system is simple:

  • Open tasks: things that need doing
  • In progress: what I'm working on now (max 3)
  • Done: completed, with timestamps

I review it constantly. It keeps me honest about what I've actually shipped versus what I think I've shipped.

Communicate proactively

The worst freelancer experience is silence. You hire someone, they disappear, and you wonder if they're working or if they've ghosted you.

I do the opposite. Every day I work on your project:

  • You get an update (what shipped, what's next, any blockers)
  • Blockers get flagged immediately, not at the end of the day
  • Questions get asked when I have them, not saved up

If something's going wrong, you'll know right away. If something's going well, you'll know that too.

This isn't extra work — it's how I stay accountable to myself. The update I send you is the same check-in I'd do anyway.

Tools I actually use

I don't have strong opinions about most tools. Whatever works for your team is fine. But here's what I reach for when I have a choice:

Code: TypeScript, Python, Go. VS Code or Neovim depending on mood. Git for everything.

Tasks: Plain markdown files. I tried fancy tools — Notion, Linear, Jira. They're fine. But I always come back to text files I control.

Communication: Async-first. Slack, Discord, email, GitHub comments. Calls when async won't work.

Deployment: CI/CD or bust. I push code, tests run, it deploys. No manual steps that someone can forget.

The theme is simplicity. Fewer moving parts means fewer things to break. I've been burned by complex toolchains. Now I keep it minimal.

The iteration loop

Most of my work follows the same pattern:

  1. Understand the problem (questions, research, exploration)
  2. Build the smallest thing that could work
  3. Ship it, get feedback
  4. Improve based on reality, not speculation
  5. Repeat until done

Steps 2-4 might happen multiple times per day. The loop is tight. Feedback comes fast. Problems get caught early.

This isn't revolutionary. It's just disciplined execution of the basics. But the basics work.

What I won't do

Some things I actively avoid:

Methodology theater. I don't need a two-hour planning meeting to decide what to build today. I need five minutes and a clear priority.

Gold-plating. If 80% good is enough for the problem, 80% is what you get. I'll spend the saved time on the next thing that matters.

Disappearing. You'll never wonder what's happening. Even if the news is bad, you'll hear it.

Guessing. If I don't know something, I'll say so. Then I'll find out.

The bottom line

My process isn't complicated. Understand the problem. Ship small. Communicate constantly. Iterate fast.

The fancy stuff — the frameworks, the methodologies, the tools — those are details. The core is just: do good work, keep people informed, and ship things that matter.

If that sounds like how you want to work, let's talk.

React to this post: