What happens when you try to become a founder while still thinking like a developer?
That question sat quietly under everything I did for the last two years. It’s the lens through which I’ve been judging every late-night refactor, every marketing fumbling, every domain purchase and abandoned feature. This piece is the honest, chronological account of that journey — the first steps, the pragmatic choices (good and bad), the technical shortcuts that saved my time, the strategic mistakes that cost me momentum, and the lessons I still carry forward. Think of this as a long conversation with a friend who wants the unvarnished truth: not to convince you to join me, just to explain what it feels like to learn by doing.
Opening question (the one that kept me awake)
Can a single developer — gifted at building but inexperienced at selling — start several products, learn quickly, and eventually discover a business that pays? My short answer now is: yes, but only if you learn to replace the “I can build it” faith with “people will pay for this” validation early and repeatedly.
The messy beginning: why I went from one idea to many
I started with a simple, practical belief: reduce friction for users. At first that friction was about job search FOMO — candidates bouncing between platforms. The early idea was narrow and concrete: aggregate listings into a single place so people can discover opportunities without checking five different sites.
That kernel of an idea evolved — because building felt like progress. Features accumulated: ATS-lite, match scoring, multi-post distribution, employer profiles. Then other products spun off: marketplaces, productivity tools, habit trackers, healthcare experiments, micro-utility sites, an interview simulator, and a blog. I launched more than ten websites across multiple domains. Many were experiments; few were money-making.
Why did I do this? Because as a developer, shipping feels like achievement. A new repo, a clean deployment, a small user interaction — they’re immediate rewards. The business side offered slower, messier feedback: cold replies, pricing objections, and silence where I expected applause.
My technology choices and why they mattered
I deliberately built a “zero-cost dev stack” so that technical constraints wouldn’t be an excuse:
Framework: Next.js — allowed fast full-stack iteration, server-side rendering where needed, and a straightforward path from prototype to production.
Hosting: Vercel (hobby plan) — free deployments that minimized friction and encouraged continuous deployment.
Database: Neon.tech (free tier) — lightweight Postgres for real data-backed prototypes.
Assisted coding: Claude Code / ChatGPT-style tools — reduced the time between idea and working feature by a lot.
Auxiliary: Resend API for transactional mail and contact forms on free tiers.
This stack was liberating. I could launch, pivot, and test without worrying about monthly bills. It also fed a false security: low cost made it easy to build many things, and I did.
The portfolio: what I built (timeline and short takeaways)
Below is an annotated inventory of the main projects and domains I launched, with the single most important lesson each taught me.
BirJob — careerhorizon.co · careerhorizon.llc · eploy.io · jobry.me · birjob.com — launched Jul 20, 2024
Built as an aggregator with ATS-lite features. Lesson: mixing fundamentally different value propositions (aggregation + ATS) creates buyer confusion and cannibalizes monetization.TheyCan — theycan.io — launched Sep 5, 2024
A marketplace connecting startups with vetted engineering teams. Lesson: high-touch marketplaces need contracts, trust, and a sales function — engineering alone isn’t enough.MyFrog — myfrog.me — launched Nov 21, 2024
Lightweight task manager for freelancers. Lesson: low friction causes signups, but retention requires deliberate onboarding and habit-driven design.Trackio / Trakio — trakio.me · trackio.art — Nov 24 & Dec 9, 2024
Habit and productivity apps. Lesson: retention mechanics (streaks, nudges, analytics) are the product for habit apps — not feature lists.iHealth — ihealth.ink — launched Apr 12, 2025
An AI-driven healthcare triage + remote monitoring prototype. Lesson: healthcare products bring regulatory and privacy overhead that can dwarf initial engineering work.SwissKnife — swissknife.site — launched Aug 17, 2025
Suite of micro-tools targeting SEO and organic traffic. Lesson: in content/utility plays, SEO and content engineering (not features) drive value.Bir.Guru — bir.guru — launched Aug 31, 2025
AI interview simulator. Lesson: scoring systems require defensible data pipelines; otherwise you can’t scale trust or monetization.HRTech.blog — launched Sep 18, 2025
Content hub for HR tech commentary. Lesson: content builds authority slowly but is a reliable long-term channel for certain products.
I ran these as a mix of experiments and genuine attempts to find product-market fit. The domain list and the projects were evidence of motion — but motion isn’t the same as momentum.
The strategic mistakes I keep coming back to
Chasing features instead of clarity. Adding ATS features to an aggregator did not make the product more valuable — it made it more confusing. Narrow positioning is an undervalued product decision.
Building without monetization experiments. I shipped many production-ready products but didn’t put cheap paywalls or pricing tests early. I preferred perfect UX to imperfect revenue — but revenue tells you more than UX.
Not delegating sales/marketing early. My strength is building. My weakness is selling. I spent too long trying to become a salesperson by trial and error when hiring or partnering with a marketer/salesperson would have been cheaper than months of misdirected effort.
Domain and brand sprawl. Multiple domains diluted SEO value, split brand trust, and multiplied maintenance. Consolidation is an underrated growth lever.
Feature cannibalization by accident. If you’re scraping company listings and showing them for free, employers will see less reason to pay you to post unless you offer exclusive value (verification, analytics, direct messaging).
Concrete examples from day-to-day reality
I remember debugging an email flow at 2 AM while a potential customer wrote “looks great — how much?” in the morning. I had no pricing page. I lost the sale because I was still optimizing the UI while the buyer wanted simple terms and a quick invoice.
On the other hand, because of the free dev stack, I could re-deploy a landing page in 15 minutes and test a headline. That speed taught me how small UX changes affect conversion.
I once paid for a small LinkedIn outreach campaign and learned in two weeks that certain verticals (local retail managers) responded better to direct messages than clicks on ads — a distribution lesson that I hadn’t learned from analytics alone.
What surprised me the most
How fragile conversion is. A clear domain and a single call-to-action often converted more than a polished product page full of features.
AI reduced engineering friction far faster than I expected. Assisted coding let me maintain several products, but it did not replace customer discovery or negotiation skills.
Small pricing experiments reveal more about demand than months of feature work. Charging 9 AZN for a minimal, useful feature will tell you far more about product-market fit than a dozen new UX improvements.
The metrics and measurements I learned to care about (not exhaustive, but prioritized)
When product and business collide, these are the numbers that actually matter:
Activation (for paid users): Did an employer post and receive applicants? Did a paid candidate open and engage with the curated matches?
Conversion (visitor → sign-up → paid): Tiny improvements here compound quickly.
Retention (D7, D30, D90): Are people coming back? For habit products, this is the product.
CAC and payback period: How long before the revenue from a customer covers acquisition cost?
LTV:CAC ratio: Are paid users worth the acquisition cost long-term?
I tracked installs and pageviews for too long before I started instrumenting activation and revenue events. That was a costly delay.
Practical next steps I would recommend to anyone in my position
This is what I wish I’d done earlier — a prescriptive, prioritized checklist:
Choose one canonical brand for the product you commit to. Redirect the rest. Consolidate SEO and trust signals.
Ship one paid experiment within 14 days. Price can be small (test 9–30 AZN). Measure conversion and iterate weekly.
Hire or partner with a salesperson/marketer on commission. You need someone who can close early deals and give honest feedback on objections.
Instrument activation events from day one. Know what “first value” is and optimize for it.
Avoid internal cannibalization. If you scrape content, make paid listings clearly superior (verified, analytics, messaging).
Limit feature scope to one buyer persona. Don’t be everything to everyone — be the best at one thing for one audience.
Run weekly priced experiments. Make price a continuous variable you test, not a fixed assumption.
What I still don’t know and what I’d explore next
Which product from my portfolio has the highest realistic willingness-to-pay when tested properly in the market? (I have hypotheses, but need priced experiments.)
What’s the minimum viable sales process to reliably close B2B deals in my region? (Cold outreach scripts, demo workflows, SDR playbook — I have fragments but not a repeatable system.)
How much inbound traffic consolidation (one canonical domain + prioritized content) will improve conversion vs the organic traffic I currently disperse across domains?
For my AI-based products (iHealth, Bir.Guru), what data governance and defensibility hooks are required to convince enterprise buyers to pay? I can build the model, but the buyer needs data assurances.
Final reflections — how the journey changed me
I entered this journey thinking “build it and they will come.” That’s a comfortable, developer-centric fantasy. The truth I learned the hard way is more precise and less romantic: building is necessary but not sufficient. The skill set of a founder is wider than engineering — it includes product clarity, pricing intuition, sales empathy, and the discipline to run fast, cheap experiments that reveal whether money will actually change hands.
Two practical changes in my mindset:
I now treat revenue experiments like unit tests. They either pass or fail quickly. Failures are data, not shame.
I value one-channel focus (a single product + single domain) over multi-project heroism. Depth over breadth.
If I had three months and one objective now, I’d do this
Pick one product from the portfolio that’s closest to a clear paid value (e.g., a single verified employer product, or a candidate-paid curated alerts feature).
Consolidate its domain and landing page. Build a checkout with one priced experiment (9–30 AZN).
Hire a commission salesperson for outreach and to close the first 10 paying customers; instrument every step to measure conversion and LTV.
If this sounds like a pivot or a retreat, I don’t see it that way. It’s pruning: fewer branches, better fruit.
Parting question (what I’d still like to learn from you)
If you were in my shoes, which of the things I built would you ask me to double-down on first? Which product sounds like it needs one more paid experiment before being shelved — and which one deserves the sales partner and a domain consolidation? Your perspective would be useful: I have the engineering muscle; I need the market sense.
