How to be that dev/swe: What you need to do, challenges you need to conquer to own that identity?
We have all been there. It is 2:00 AM. Your IDE is open. You have three tabs of Stack Overflow, a half-finished tutorial, and a sudden, burning desire to reorganize your bookshelf. You are not building; you are "preparing to build." The gap between being a "coder" and being a "Software Engineer" (or a founder) is not measured in LeetCode problems solved. It is measured in execution velocity. If you want to be that developer—the one who ships products, earns income, and actually finishes what they start—you need to deconstruct the psychology of building. Here is the blueprint.
Timothy Mutwiri
19 / 8 / 2026 ·
Part I: The Enemy Within (Killing Procrastination)
You are not lazy. Laziness is a myth. Procrastination is actually emotional regulation. You avoid the task because it feels overwhelming, ambiguous, or you fear it won't be perfect.
The "Draft" Mentality
Developers suffer from "Architectural Purity" syndrome. We want the code to be elegant on the first pass. Kill this.
- Action: When you sit down, your only goal is to create a "Vomit Draft." Write the ugliest, most brute-force code that technically solves the problem. You are not building a skyscraper; you are building a scaffolding. You can refactor the scaffolding later. But you cannot refactor a blank screen.
The 5-Minute Rule
If you don't want to work on your project, commit to working on it for exactly 5 minutes. Set a timer. Usually, the activation energy to start is higher than the energy to continue. Once you fix that one typo, you will likely spend an hour coding.
Time Boxing over Time Tracking
Don't track how long you work; define what you will achieve in a specific window.
- Just focus, one mind one task. "I will implement the authentication flow in 45 minutes."
- If it takes longer, stop. Reduce the scope of the feature. Time boxing forces you to compromise and ship, rather than gold-plating.
Part II: The Compass (Setting Goals that Stick)
This has always been a motivational factor to start a project "i/we need to build a SaaS" should not be the goal. It is a dream. Goals need to be atomic.
The "Golden Circle" of Features
Before writing a line of code, ask yourself:
- The Why: What specific user pain does this solve?
- The How: What is the simplest technical path to that solution?
- The What: What are the exact features needed?
SMART-ER Goals
Make them Specific, Measurable, Achievable, Relevant, and Time-bound. Then add Evaluate and Readjust.
| Bad/Good | Goals |
|---|---|
| Bad | Get better at Python. |
| Good | Build a REST API endpoint that handles file uploads by Friday, using FastAPI. |
The "Done" List
A to-do list is a list of failures waiting to happen because you never finish it. Write a "Done" list at the end of the day. This provides a dopamine hit and shows you are making progress, even if you didn't finish the entire project.
Part III: The Blueprint (What to Understand Before Building)
A hammer doesn't build a house; the carpenter does. The language (React, Python, Go) is just the hammer.
1. Data Flow > Syntax
Understand where the data lives, how it moves, and how it changes state. If you understand the state machine of your app, the code writes itself.
2. The Pareto Principle (80/20)
80% of your users will use 20% of your features. Identify that 20% (the "Core Loop"). Build that first. Do not build a dashboard, a graph, or a settings page until the core action (e.g., uploading a file or processing a payment) is flawless.
3. The Database is King
Most performance issues are bad database queries, not bad code. Spend time learning indexing, query optimization, and database design before you learn the latest frontend framework.
Part IV: The Vehicle (Why SaaS is the Ideal Project)
You want to learn, but you also want to earn. Why is Software as a Service (SaaS) the perfect sandbox for a developer?
1. The Ultimate Full-Stack Education
Building a SaaS forces you to touch everything:
- Frontend: UX/UI design.
- Backend: API architecture and security.
- DevOps: Deployment, scaling, and monitoring.
- Business: Payment processing and customer support. It is the best "Masters Degree" you can get for free.
2. Recurring Revenue Engine
A one-time freelance gig pays you once. A SaaS pays you every month. The "Subscription" model acts as a "Force Multiplier" for your effort. You build it once, and if you solve a painful problem, you get paid forever.
3. Immediate Feedback Loops
If you build a library, nobody uses it. If you build a SaaS, you can watch users click (or not click) in real-time. That feedback loop is the fastest way to improve your engineering judgment.
4. Low Risk, High Reward
The cost to host a SaaS is pennies compared to a physical store. The risk is minimal. The upside is an asset you can sell or scale.
Part V: The Earning Ecosystem (Ways to Make Money)
Don't just build one thing and pray. Diversify your income streams as a developer.
- The "Micro-SaaS": Solve a niche problem for a specific industry (e.g., "Scheduling for Dental Hygienists"). Charge $29/month. Get 100 users. That is $2,900 MRR. This is easier than building a "Facebook killer."
- The "Tool" (Open Core): Build a developer tool that is free for individuals but charge enterprises for SSO, audit logs, and support.
- Consulting + Product: Use your SaaS as a "Loss Leader." If a client needs a custom version, charge them a high implementation fee to build it, which then improves your core product.
- Digital Products: Sell templates, boilerplate code, or "Starter Kits." If you are good at setting up Auth, Payments, and Emails, sell that as a template so other devs don't have to do it.
Part VI: The Unspoken Truths (The "Other" Topics)
1.Resilience > Intelligence
You will hit a bug that takes three days to fix. The market will reject your v1. The difference between a junior and a senior is that the senior knows they will eventually fix it. Patience is a technical skill.
Marketing is Code
Your product is not finished when you deploy it. It is finished when the user uses it. Spend 50% of your time coding and 50% of your time talking to users, writing documentation, and making "How-to" videos. Code is just the cost of entry; distribution is the prize.
The "Boring" Stack Wins
Choose the technology you know best, even if it is "uncool." Node.js, PHP, or Ruby on Rails can handle millions of requests if configured properly. Avoid "Shiny Object Syndrome." A boring, stable stack allows you to ship faster.
Maintenance is the Real Job
Building is fun. Maintaining is work. Design your code to be easy to delete, not just easy to extend. Simplicity over complexity.
Art is perfect, because it took time.
Forget the "10x Engineer." Aim to be the 1x Engineer who ships.Stop reading articles. Stop agonizing over the database schema. Close the Reddit tab.Open your terminal.Type npm create or cargo new or go mod init.Type git add . and git commit -m "v1: It's ugly, but it works."Push to production.
The world doesn't need more code. It needs more solutions. Go build one.