Three Months as a Former Developer, Product Person, and Accidental One-Man R&D Lab
I have a confession to make.
I have spent years around software while barely writing software.
Not because I stopped caring about engineering. Quite the opposite.
Like a lot of people who drift toward senior product, technical leadership, architecture decisions, escalations, delivery, and business strategy — I slowly moved further from active coding and closer to judgement.
My job became less about typing code and more about making decisions around it.
Architecture conversations. Technical escalations. Product trade-offs. Roadmaps. Failure scenarios. Risk. Operational reality.
“What happens when this breaks?” “Will this scale?” “Why are developers unhappy?” “What technical debt are we quietly creating?” “Can the business actually support this decision six months from now?”
You stop living in implementation and start living in systems.
You still understand engineering. You just stop touching it every day.
And somewhere along the line, if you are not careful, you convince yourself that coding became somebody else’s problem.
Then something funny happened.
Or slightly irresponsible, depending on how charitable you are feeling.
I started building again.
Not in the “raise capital and hire a team” sense. Not in the “carefully planned startup” sense.
Just me. One person. A few subscriptions. Some curiosity. A suspicious number of ideas. And a deliberate willingness to ignore parts of the engineering maturity I spent years accumulating.
That last sentence deserves context.
Because this is not a story about AI replacing engineers. And it is definitely not a story about process being useless.
It is a story about timing. About curiosity. About economics. About rediscovering something I had not felt in years. And perhaps accidentally inventing a completely different personal software development lifecycle along the way.
Month One: Curiosity Beats Process
Around three months ago I started experimenting. At first, casually. Almost as a personal challenge.
Could someone who had mostly stepped away from active coding still build useful things?
More importantly — what even counts as “building” now?
Because this no longer felt like traditional software engineering.
The old mental model: Requirements. Design. Architecture. Build. Test. Deploy. Support. Repeat.
And yes — before someone panics — I understand why that exists. I have lived enough enterprise reality to know maturity matters. Standards matter. Governance matters. Testing, code reviews, source control, security — all of it matters.
But something felt different in this new environment.
The cost of trying had collapsed.
And that changes behaviour.
So I made myself a rule:
One twenty-dollar subscription at a time.
No giant software stack. No premium everything. No enterprise tooling. No unlimited agent credits. No throwing money at the problem.
One service. Twenty dollars. Use it properly. Understand it. Work around the constraints. Move on.
The funny thing about constraints is that they make you creative. Scarcity sharpens attention. You stop wasting prompts. You stop pretending infinite tooling equals productivity. You become intentional.
And so began what I can only describe as a weird personal experiment: what happens if a former developer — now mostly a senior business and product person — tries to build like it is Grade 10 school holidays again, except older, more mature, and with actual economic understanding?
Grade 10 Energy. Adult Consequences.
This part caught me off guard.
Because emotionally, something old came back.
I remembered coding over school holidays. Not for money. Not for career progression. Not for architecture governance. Not for Jira tickets.
Just because building things felt fun.
Pure curiosity. Hours disappearing. Late nights. Breaking things. Fixing things. Making weird little ideas. Sometimes useful. Sometimes pointless. Mostly exciting.
And suddenly, somewhere in my thirties, I found traces of that again.
Except now there is business judgement layered on top. Economic understanding. Product instincts. A better feel for incentives, users, markets, operations, risk.
Ironically, being older made the fun better.
Because you stop romanticising endless effort and start appreciating leverage.
You stop asking “How hard can I work?” and start asking “How quickly can I learn? How cheaply can I test? How fast can I validate? How soon can I know if this deserves to exist?”
That shift feels important.
Because the economics have changed. Massively.
Codex, Claude and the Sculptor Developer
My experience with coding agents has been strange. Strangely practical. Strangely creative. Occasionally frustrating. And surprisingly emotional.
Sometimes with Codex-style workflows I could get two-to-three-hour sessions where things moved absurdly fast. Feature. Adjustment. UI fix. Flow. Bug solved. Prototype suddenly exists. Coffee barely cold.
The thing works. Not beautifully. Not perfectly. But enough. Enough to feel momentum. Enough to see shape. Enough to test whether an idea deserves oxygen.
The best word I have found for this is sculpting.
Because this no longer feels like traditional coding.
You are not chiselling every line manually. You are shaping. Directing. Stepping back. Observing. Adjusting. Testing proportions. Changing form. Removing weight. Rebuilding. Walking away. Coming back.
Building became conversational, not mechanical.
You stop obsessing over implementation and start obsessing over judgement. Should this exist? Does this flow make sense? What architecture decision feels fragile? What becomes expensive later? What deserves hardening?
The bottleneck shifts. Implementation friction drops. Judgement suddenly matters more. Taste matters more. Architecture matters more. Product thinking matters more.
Which is slightly terrifying and slightly exciting — often simultaneously.
Then There Is Claude.
Claude is brilliant sometimes. Infuriating sometimes. Burn-through-your-credits-in-thirty-minutes funny.
You are flying — deep architecture discussions, strong reasoning, framework thinking — and suddenly you hit limits. Now you wait four and a half hours.
At first I found this infuriating.
Then something weird happened.
The waiting accidentally helped.
But here is what I genuinely came to admire.
Claude planned for its own constraints.
That three day architecture rebuild? Claude knew it could not do it in one sitting. So it didn’t try. It thought ahead. Mapped the work. Structured the sessions. Knew what needed to happen in sequence. Knew what depended on what. Knew where to stop cleanly so the next session could pick up without losing the thread.
My entire contribution across those three days?
Typing the word continue three times a day.
That’s it.
And out the other side came a near production ready app with a cleaner architecture than the one I started with.
There is something almost elegant about a tool that understands its own limits well enough to work gracefully within them. No pretending. No overreaching. Just honest, structured execution across the time it actually had.
Most humans are worse at that than Claude was.
And the waiting? It accidentally helped too.
Because the latency forced reflection. You go outside. Talk to people. Walk around. Have coffee. Do life. And somewhere mid-conversation or halfway through a random errand, your brain quietly solves product problems.
That flow is wrong. The onboarding needs changing. That architecture feels risky. This feature is actually useless.
The app shifts shape because life entered the loop.
I increasingly think boredom and waiting are underrated parts of product development. Sometimes the best thing for software is not another sprint. Sometimes it is walking around for four hours because your credits ran out.
The Part Enterprise Engineers Might Hate
Here is the thing.
Most days? My setup is mildly chaotic.
Sometimes I barely touch Git. Sometimes I ignore merge concepts entirely. Sometimes I just zip the local codebase with a filename no reasonable person would accept.
“working-final-v2-final-real.zip”
Future me can deal with the consequences.
Now before senior engineers collectively faint:
Yes. I know. I know why this is terrible. I have lived long enough around production systems to understand exactly why standards exist.
Code reviews matter. Source control matters. Testing matters. Security matters. Build processes, resilience, governance, operational maturity — all of it matters.
But context matters too. Because context determines what you optimise for.
And right now, I am intentionally optimising for discovery.
That distinction matters more than most organisations are willing to admit.
Enterprise engineering optimises for certainty. Discovery engineering optimises for possibility.
Those are not the same thing. And pretending they are is where a lot of creative energy quietly dies inside organisations that should know better.
If I am trying to discover whether an app deserves to exist, spending three weeks designing perfect governance around an idea that may die in forty-eight hours is not diligence. It is theatre.
Mess first. Discipline later. Prototype first. Production maturity second.
Not because maturity is unnecessary. Because sequencing matters.
The New SDLC I Accidentally Built
Around month two I realised I had unconsciously evolved a weird personal systems development lifecycle.
Not formal. Not documented. Definitely not enterprise approved. But strangely effective.
Phase One: Curiosity
This thing would be cool.
That’s it. No roadmap. No requirements document. No strategy deck. No stakeholder workshop.
Just a feeling. A random observation. A problem. Something I wish existed. Something annoying. Something funny. Something potentially useful.
Historically this phase dies quickly because implementation is expensive. Now? Curiosity survives longer. And that matters, because the number of ideas you can cheaply explore suddenly explodes.
Phase Two: Sculpting
This is the dangerous fun phase. Fast. Messy. Creative. Slightly irresponsible.
You build. Prompt. Adjust. Delete. Retry. Test. Walk away. Return. Suddenly features appear before you finish coffee.
This is where people misunderstand the shift. AI did not magically remove work. It changed the texture of work.
You stop being a typist. You become a sculptor. You shape, direct, critique, make judgement calls. You still need technical thinking — actually maybe more than before. Because bad judgement compounds faster too.
Phase Three: Latency, Boredom and Accidental Product Thinking
Nobody really talks about this phase.
The waiting phase. The “you burned through credits and now what?” phase.
You burn through thirty minutes asking architecture questions, challenging assumptions, debating frameworks, fixing logic — and suddenly the meter says: come back later.
So you stop. And something unexpected happens.
You become a user.
You pick up the app. You tap through it like someone who has never seen it before. You try to break it. You find the flow that almost works but doesn’t quite. You hit the screen that made perfect sense at 2am and makes no sense now. You notice the button that is one tap too many. The onboarding that assumes too much. The feature you built proudly that nobody would ever actually use.
You show it to someone. Not a developer. Not someone who will be kind. Someone who will just use it — or won’t — and either reaction tells you everything.
And you watch their face, not the screen.
You start thinking differently. Not in code. Not in architecture. In questions.
Is this actually useful or just technically interesting? Would someone pay for this — and if so, how much, and why? Is the pricing model honest or am I just guessing? What is the real reason someone opens this app? What is the real reason they would delete it? How would I explain this to someone in one sentence? Would that sentence make them curious or confused?
You walk around. You sit in traffic. You have a conversation that has nothing to do with software. And somewhere in the middle of something completely unrelated, the product tells you what it actually wants to be.
The onboarding needs to go. That feature is a distraction. The pricing is wrong — not the number, the entire model. The marketing angle you had is clever but the real one is simpler and more honest.
That is not wasted time. That is the work.
Because software is still about people. And people exist outside IDEs. The best product thinking rarely happens at a keyboard. It happens when you finally stop building long enough to feel what you actually made.
Phase Four: Interrogation
This is where things became intellectually fun again.
Returning to implementation after years away should have been painful. Different frameworks. Different tooling. Different patterns. Different expectations.
In another era I would have spent weeks in YouTube rabbit holes. Documentation. Forums. Course hell. Tutorial fatigue. Twenty tabs open. Stack Overflow archaeology.
Instead, I interrogated the system.
Explain this framework. Why does this architecture exist? What are the trade-offs? What security risks am I creating? What happens if this breaks? Why do engineers argue about this?
And this became a workflow hack I think more people should talk about:
Tell the AI to explain the code in comments. Comment the thing.
Explain it like I am a senior systems thinker returning to implementation. Why does this exist? What trade-offs are hidden here?
Suddenly learning collapses into delivery. You stop leaving the IDE every five minutes. You learn inside movement. Inside momentum. Inside experimentation.
For somebody like me — product-heavy, architecture-aware, hands-off from active coding for years — that changed everything.
Because the gap between curiosity and capability became dramatically smaller. Not zero. Smaller.
You still need judgement. Bad ideas remain bad ideas. Weak architecture remains weak architecture.
But the distance between “I wonder…” and “I built something…” has collapsed.
That feels historically important.
The Part Nobody Tells You About Architecture
There is a belief baked deep into professional software development.
Architecture is upfront work. You design before you build. You think before you type. You plan before you commit.
And at scale? Absolutely. That discipline exists for good reason.
But something unexpected happened in month two.
I refactored an entire app architecture across three days. Not in one marathon session. Not in a carefully planned sprint. Three separate thirty-minute sessions daily during my waking hours. Flat out. Focused. Then done.
That’s it.
In a relatively small codebase, the cost of getting architecture wrong and then fixing it turned out to be lower than I expected. Dramatically lower. Because the same tools that helped me build fast also helped me rebuild fast. The sculptor metaphor holds — sometimes you tear down a section entirely and start that part again. Not because you failed. Because you learned something by building it wrong first.
There is something almost counterintuitive here that enterprise thinking struggles with.
Upfront architecture assumes you know enough at the start to make good decisions. Sometimes you do. Often, especially in early product discovery, you don’t. You learn by building. You discover the real shape of the problem by touching it. And then you fix it.
The rework is not the failure. The rework is the process.
Three days. Three short sessions. Different architecture. Better product.
No committee. No design document. No approval cycle.
Just a willingness to tear it apart and try again.
And here is the part that should make some people uncomfortable.
That app is near production ready.
Not despite the chaos. Not despite the short sessions and the messy middle and the architecture that got thrown out twice. But almost because of it. Because every rebuild was informed by something the previous version taught me. Because I was not defending decisions. I was chasing the right answer.
Economics is value creation. That is it. That is the whole game.
And a small, clean, focused codebase that solves a real problem is worth infinitely more than a sprawling, well-governed architecture solving the wrong one.
Bigger is not better. More complex is not more valuable. More lines of code is not more product.
Sometimes the best version of a thing is the leanest version. The one that had the courage to cut. The one that got rebuilt three times in a week until it finally felt right. The one that looks almost too simple from the outside — because the mess happened on the inside, privately, cheaply, quickly, before anyone was watching.
That is not a junior mistake dressed up as a philosophy.
That is how good products actually get made.
Somewhere Around Month Three…
Somewhere around month three I realised something slightly ridiculous.
I may have accidentally built a tiny R&D lab.
One shipped app. One nearing commercialisation. Five prototypes in various stages of usefulness, chaos, confusion, possibility and “what was I even thinking?”
Some will go nowhere. Some are just learning tools. Some are architecture experiments. Some might become businesses. Who knows.
What surprised me most was not productivity. It was optionality.
The sheer number of things one person can now reasonably test. Not perfectly. Not beautifully. Not enterprise-ready. But enough to learn. Enough to validate. Enough to throw away. Enough to decide: this deserves another week — or — this dies here.
That feels economically different from anything I have experienced professionally.
Historically, experimentation carried cost. Budget. Teams. Politics. Prioritisation. Approvals. Engineering capacity.
Now? A curious person with twenty dollars and enough stubbornness can build surprisingly far.
That sentence still feels slightly absurd. And completely true.
The First App and a Tiny Vote of Confidence
My first app got approved for the Apple App Store in under twelve hours.
That surprised me. Not because I suddenly think I built the next billion-dollar platform — let’s calm down. But psychologically it mattered.
Because when you have been mostly hands-off coding for years, there is a strange vulnerability in shipping again. You quietly wonder: Did I completely lose it? Am I building nonsense? Did I accidentally create chaos held together by hope?
Seeing something get through review that quickly felt like a tiny vote of confidence. Not proof of greatness. Not proof of product-market fit. But proof that I had built something sound enough. Coherent enough. Real enough. Enough to exist in public.
That mattered more than I expected.
Then came the next real test.
Because the second app feels different. Payments. Commercial intent. More complexity. More checklists. More things that trigger scrutiny. More reasons for somebody to say: “Hang on…”
This is the actual exam. The first app proved I could still ship. The next one tests whether I can commercialise responsibly. Different game. Same curiosity.
Time will tell.
And honestly? That uncertainty is half the fun.
The Adult Version of Grade 10
The weirdest emotional part of this entire experiment is how familiar it feels.
Grade 10. School holidays. Coding for absolutely no rational reason. Not because somebody paid me. Not because there was strategy. Not because there was business value.
Because it was fun. Because making things felt exciting. Because computers felt like possibility.
Somehow, three months into this, I have found traces of that feeling again.
Except now there is maturity layered on top. Economic understanding. Business judgement. Product instincts. Operational awareness. Pattern recognition. Architecture thinking.
The difference is speed. Back then it took forever to get anything meaningful working. Now you can move from idea to prototype in days. Sometimes hours.
That sentence alone still feels slightly ridiculous to me.
And maybe that is the real story here.
Not AI. Not tooling.
Leverage.
The leverage changed.
You still need thinking. You still need judgement. But the economics of experimentation shifted so dramatically that building starts feeling playful again.
Which makes me think about what comes next.
Because if a former developer in his thirties — rusty, relearning, working around credit limits and zipping folders with embarrassing filenames — can accidentally build a small R&D lab from a laptop and some curiosity, then something much bigger is coming.
The next wave does not belong to the enterprise. It does not belong to the well-funded. It does not belong to the teams with the best governance frameworks and the most approved tooling.
It belongs to whoever has the best idea, a blank canvas, and the stubbornness to try.
And that person might be seventeen years old.
Sitting in their bedroom. No team. No budget. No roadmap. No stakeholder approvals. Just a laptop, twenty dollars of spending money, some free time, and an idea they cannot stop thinking about.
And for the first time in the history of software, that might actually be enough to build something worth a million dollars before they ever leave school.
Not because the tools are magic. Because the barrier between imagination and execution finally got small enough for curiosity alone to clear it.
That changes everything.
My first iOS app – Prompt Me – Guided Journalling.
Completely free in support of guided introspection and journalling as a wellness tool.