Indie Maker as a Software Engineer

Where does your engineering skill actually help, and where does it hurt?

Your ability to build is real leverage. A working web app that would cost a non-technical founder several thousand dollars in freelancers, you can stand up over a weekend, iterate on for free, and throw away when you learn you built the wrong thing. That cost advantage is the entire reason the employed-engineer path works at all. But "I can build anything" is also why most engineer side projects quietly die: the same skill that lowers your build cost lowers your resistance to building things nobody asked for.

The parts of indie making that decide whether money shows up are the parts engineering never trained you on: choosing a problem people already pay to make go away, writing a landing page that converts a stranger, and getting the first hundred humans to even see it. Treat those as your hard problems now. The code is the easy part, and for a senior engineer, saying that out loud is the mindset shift that takes the longest to accept.

• →Transfers directly: shipping fast, debugging under pressure, automating your own ops, reading docs, and evaluating tools cheaply
• →You have to learn from zero: positioning, pricing, landing-page copy, and running one distribution channel long enough to work
• →Actively unlearn: gold-plating, premature scaling, and treating code quality as the goal instead of a means to a paying user

Can you build side products without breaking your employment contract?

This is not legal advice, but it is the specific worry that freezes engineers before they start, and it has concrete answers. Most tech employment agreements contain an IP-assignment clause, and many add a moonlighting or outside-activity policy. The two things that actually cause trouble are building in your employer's market and using company time or equipment. Both are avoidable with plain hygiene, not lawyers.

Read the agreement and offer letter you actually signed, not your memory of onboarding. Broad language like assigning "anything created during employment" is common, and depending on your state or country, it is often narrowed by carve-outs for work done on your own time and your own hardware. The safe posture is clean separation up front, not betting later that a clause turns out to be unenforceable.

• →Build only on personal hardware, personal accounts, and outside your working hours, with no exceptions on a rushed evening
• →Don't ship a product that competes with your employer or targets the customers you serve at the day job
• →Look specifically for IP-assignment, non-compete, and moonlighting clauses, plus your jurisdiction's own-time-own-equipment carve-outs
• →If your contract requires disclosing outside projects, disclose in a short email; that beats a clawback fight after you have revenue
• →Once money arrives, keep the side income, accounts, and expenses cleanly separate from anything touching work

What should you actually build with limited hours?

With a full-time job, scope decides everything else. The products that survive an employed engineer's schedule are narrow, solve exactly one job, and sit close to the developer world you already live in. That proximity shrinks both problems at once: the build is smaller because you understand the domain, and the "who do I tell" problem is half-solved because you already know where those users complain.

Notice what the table below deliberately omits: a venture-scale platform, a two-sided marketplace, anything needing a sales team or an outside round. Those demand full-time attention and capital you are specifically choosing not to raise. Ruling them out is not settling for less, it is the whole strategy of staying employed.

How do you ship on 5-10 hours a week without burning out?

Protect the two things you actually run short on, free evenings and momentum, by refusing to spend either on anything a user will never see. Reach for the most boring stack you already know cold, put the whole thing on a managed host, and skip the infrastructure your work brain reaches for by reflex. A single region, one database, and no microservices will carry a side product to its first paying customers and well past them.

Then pick one distribution channel and one shipping cadence and hold both for months. Build in public if it suits you, but the goal is a repeated, visible motion, not a launch-day spike that goes quiet. Side products die from silence and from stop-start weeks, far more often than from bugs or a missing feature.

• →Cut any feature not strictly required for the first user to get value on day one
• →Default to managed services; a self-hosted database rabbit hole is a month of evenings you never get back
• →Ship something visible every week or two, even when it is small and slightly embarrassing
• →Pick one channel (Show HN, a niche community, SEO, or an email list) and stop diluting your effort across five

How much can you realistically make, and how long until it matters?

Set expectations to reality: most side products make nothing, and the ones that work usually crawl. A realistic early outcome for a narrow developer tool is a few hundred dollars a month somewhere in the first six to twelve months of consistent shipping, enough to prove strangers will pay you, nowhere near enough to quit. Treat that first paying customer, not the revenue number, as the milestone that changes how you think.

The real compounding happens over years, not weeks, and staying employed is what lets you reach it. Because the salary already covers your rent, no one can force you to sell, pivot, or shut down on their timeline, which is exactly the pressure a funded founder lives under. The employed indie maker isn't optimizing for a fast exit, but for staying in the game long enough that one product finally catches.