Two Engineers Ask Reddit What to Build. Top Answer: a Perfect Microservice That Made £6, and an Embarrassing Cron Job That Paid a Mortgage

An engineer posted on r/passive_income: two tech incomes in the household, one software engineer and one DevOps, looking for a side project. The framing was precise: "The issue is not building — we can build. The issue is choosing the right problem to solve." 21 comments came back, and none of them handed over a problem to solve. What the thread delivered instead is more useful. An engineer who already ran this exact experiment showed up and confessed how it went, a reader poked a hole in the confession, and two traders demonstrated in real time what arrives in every passive income thread if you wait long enough.

The perfect microservice made £6

The top comment, 19 points, from another engineer: "my first go at this was a perfectly architected microservice that solved a problem exactly three people on earth had. it made six quid in two years and i still pay the domain renewal out of spite."

The thing that made money was the opposite: "a glorified cron job that scraped a janky old api and emailed people when their council tax band changed. the tech was embarrassing but it paid my mortgage."

The advice that follows compresses the whole thread: "find something annoying in your own life, wrap a stupidly simple script around it, and launch before you're tempted to add a kubernetes cluster."

The Kubernetes line is not a figure of speech. Deeper in the thread the same commenter admits: "i once spent a weekend building a load balancer for a script that had three users. still do it now if i'm not careful." And: "i had a whole deployment diagram sketched on a napkin before i came to my senses."

Engineers know this failure mode from the inside. Architecture is comfort work. You already know how to do it, and it produces visible progress that no stranger can reject. Picking a problem and showing the result to people who might not care is the uncomfortable part, so the deployment diagram gets a third revision instead. The OP's own framing carries the symptom: "we can build" is presented as the solved half, but the £6 microservice was also built well. Building well was never the bottleneck.

The boring-problem-finder prompt in the panel runs the top comment's method as an interview, digging through your own week for checks you do by hand that a script could watch. The overengineering-tripwire prompt audits your stack plan for load-balancer-for-three-users symptoms before you spend the weekend.

"Getting users was the actual grind"

Someone asked where the script was sold. It wasn't sold anywhere: "just stuck a one-page site up with a paypal link and ran some scruffy google ads. people paid a tenner a month for the email alerts, getting users was the actual grind."

That last clause is the thread's real answer to the OP. Another commenter said it flat out: "The hard part isn't the idea or building. It's marketing. Get an audience first, because no one will know your there." A third, describing a career across engineering, architecture, and product roles: "No one care much about the product. It is all about marketing."

We heard the same thing from the one-person agency thread, where delivery was never the bottleneck, sales was. For a two-engineer household the planning question is not "which problem" but "which of us is doing the part neither of us trained for." A tenner a month, a PayPal link, and scruffy Google ads is a complete distribution stack. It is also the part of the story most engineers skim past on the way to the architecture details.

The first-users-grind prompt turns that part into a plan: one-page site, channel shortlist, and the unglamorous weekly reps, sized to how much marketing you can actually stomach.

The hole in the best story

Our standing rule is to audit money claims against their own thread, and that has to apply to comments we agree with. One reader pushed back on the cron job: "This is UK council tax right? I'm struggling to see how that made money since the council tax bands rarely if ever change and I don't really see why you would need to know before the council notifies you themselves."

No answer. The commenter returned to the thread after that question was posted and replied to someone else about distribution, but left this one alone. There may be a fine explanation. Council tax band challenges are a real cottage industry in the UK: people check whether their band is set too high and reclaim years of overpayments, and an alert service near that market could plausibly find buyers. But the thread doesn't say it. So we cite the story for its shape, the simple ugly thing beating the cathedral, and not for the mortgage math. The mortgage math went unverified the one time someone asked.

The traders arrive on schedule

Every passive income thread eventually produces a trader with a screenshot. This one produced two.

The first recommends options trading: "It requires capital, but software engineers make good money so coming up with a capital is easy for you." Attached, a chart of six months of income from trading once a week with $60K. Asked what the strategy actually is: "As they say 'volatility is vitality', its what gives you high premiums. What you'll need is risk management." That is the complete risk disclosure. A screenshot of six winning months proves that six months went well. It says nothing about what the same strategy does in a bad stretch, how much was at risk to earn it, or how many people with losing charts never post them.

The second trader day trades and points to a public posting history: entries and exits published on a subreddit, "you can check them," with a stated plan to quit at a target "before 40." Publishing a track record is audience building, and audience building is work with a payoff, which raises the obvious question: if the trades compound the way the pitch implies, what is the audience for? We've catalogued this move in DM-funnel form before; the trading version swaps the course for a following. The income-screenshot-audit prompt reads any such chart the way an auditor would: denominator, risk, window, survivorship, and what the poster gains from being believed.

What the thread actually recommends

Strip the trading pitches and the thread converges on a short list.

Find the problem in your own life, not someone else's. One commenter put ten years on that mistake: "I've wasted 10 years trying to find someone else's problem to solve. You need to find something in your life that is a directly solvable issue with your skills."

Accept the honest scale. A commenter who just launched a first mobile app reports a few sales a day and no illusions: "if I could just do this 20 more times!" One shipped small thing buys a trickle. An income is twenty of them, which is a different project than one app and worth knowing before you start.

Call it what it is. The thread's purist points out that what the OP describes is a micro-SaaS, which is a startup, which is the opposite of passive. Correct, and the taxonomy from the passive income thread has a shelf for it: a job in a costume. Fine, as long as you priced the job in.

And one suggestion was custom-built for the OP's actual skills: reviewing vibe-coded projects for a fee. One-time audits, packages, retainers. The commenter flags twice that it is not passive. But it is very 2026-shaped work: people are shipping AI-written products they cannot fully read, and an engineer couple with cloud experience is exactly who they'll pay to check the wiring.

The OP asked which problem to solve. Assembled from a £6 microservice, an embarrassing cron job, and a question nobody answered, the thread's answer reads: solve a problem you personally have, and build the version you're slightly ashamed of. Then budget most of your energy for what starts after deploy, because everyone in that thread could build, and the mortgage got paid by the one who shipped ugly and went looking for users.