Hitting $3.3k MRR in two months while working a full-time
job
Erik Chavez is a Senior Solutions Architect at Microsoft who moonlights as the founder of Jobric, an AI job-matching platform that focuses on candidates instead of employers. He launched it less than two months ago and is already at $3.3k MRR.
Here's Erik on how he's doing it. 👇
Working 5am to 10pm
I've spent more than fifteen years in cloud and platform engineering, working up from sysadmin to VP-level cloud strategy. Along the way, I've built and led Cloud Centers of Excellence, run datacenter-to-cloud migrations that saved seven figures a year, and advised everyone from seed-stage startups to Fortune 100s. I'm currently a Senior Solutions Architect at Microsoft, and I build Jobric in my own time and with my own money. Most days run from 5am to 10pm.
Jobric is an AI job-matching platform built entirely for candidates, not employers. Every other tool in this space works for whoever's paying — the recruiter. Jobric flips it: You upload your resume, set your preferences, and the platform filters the whole market down to the few roles worth your time, scoring each on how well you fit.
People hear "AI matching" and assume it's a wrapper around an LLM. It isn't. A large part of Jobric is proprietary engineering that never touches a model: the matching logic, the scoring, and the data work enabling the rest. On top of that, I run a set of small language models in-house. The AI handles the narrow things it's good at, and the engineering underneath keeps the matches accurate and the cost profile low enough that I can fund this indefinitely if I have to.
We launched on May 1, and we're already at $3,300 MRR, entirely from candidates who converted after the public beta and paid out of their own pockets. The signal I care about is the paid conversion underneath it. The whole industry assumes candidates won't pay because job boards and platforms like LinkedIn and Indeed have trained everyone to expect free. Turns out they will, when the product works for them.
Right now, I'm focused on how far it scales organically before funding becomes the right move.
Building for the people
I built Jobric for someone I love who was stuck in a job that was draining them. After a stressful day, the thought of going home and searching for another job was unbearable. They knew I worked in tech and was deep in AI lately, so they asked if I could build them an "agent" that would watch job postings in their field and email them regularly with roles that matched their resume.
I figured it would be a fun side project. But as I built it and started getting their feedback, something clicked. They were genuinely excited, and the thing surfaced roles that were both strong matches and recently posted. That's when I realized this wasn't just useful for one person. It could matter to almost anyone.
The real tipping point came when I tested it on my own profile. A job hit my inbox, and my honest reaction was, "Oh wow, I almost want to apply for this." I never would have looked at the role on my own because its title wasn't typical for my field, so I would have scrolled right past it. The product saw a fit I wouldn't have. That was the moment I decided I had to get this out into the world.
From there, it became a mission to build a "for the people, by the people" product. Talk to almost anyone, and you'll hear the same thing: applying for jobs is miserable. Ten rounds of interviews, endless applications, no signal back. Everyone knows the pain, and the current "solutions" don't help. The "use our tool to blast 1,000 applications and we'll auto-rewrite your resume for each one" approach isn't realistic, and everyone applying for jobs knows it.
Realizing the true complexity
Building the first version for one person made providing the AI enough context trivial. Testing it on myself yielded similar results. It appeared to work. Then I asked a friend for their resume, fed it into the early Jobric system, and it completely failed. This person works in cybersecurity, but the system interpreted their background as physical security, like a security guard. The reason: their most recent title was "Security Officer," which, on its face, says nothing technical. The AI took the words at face value, misinterpreting the entire person.
This led me down a path that revealed a non-technical problem. The real problem was human: How do you accurately identify what a person does and, just as importantly, what a job description asks for, when titles lie and language is inconsistent?
Consequently, most of my initial time and money went into research, not code. I focused on figuring out which data points matter, what's publicly available, and how to use engineering first and AI second to achieve accurate matching. My biggest early expense involved running endless tests against every resume I could find. I used personal savings to fund it, knowing it was a worthwhile bet.
The build has remained lean because I know cloud architecture well enough to keep infrastructure costs low, and I can perform much of the hard engineering work myself, avoiding expensive model calls.
I haven't handled the parts outside my expertise alone. As Jobric developed, I brought on fractional advisors to cover areas a solo technical founder cannot: a CISO for security, a general counsel for legal, a CFO for finance, and an exited founder for the operational and go-to-market side. This ensures I don't figure out the rest in a vacuum.
A containerized stack
Our stack divides simply:
Python runs the "brain."
TypeScript/Node runs everything the user touches.
The AI and data work — parsing a resume, classifying a candidate into the right career family, scoring how well they fit a job — use Python because it's the native language of modern AI tooling and hosts the best libraries and model SDKs.
Next.js (React/TypeScript) powers the candidate app and our partner portal, providing a fast, modern web experience and allowing a small team to move quickly.
I containerized from day one. Many services share a foundation at the dependency level, so a handful of base images underpin everything, making on-demand scaling straightforward from the start. Architecturally, I'm most proud that almost nothing runs all the time. Expensive work — fit analysis, company briefings, job matching — is on-demand. Each piece is a self-contained containerized service that wakes up, performs its job, and then goes quiet. We coordinate it all through a message queue, which reliably hands off work and allows each piece to scale independently with demand. The payoff is cost and reliability: We don't pay to keep a giant always-on machine idling, and a spike in one area doesn't take the rest down.
For the AI itself, I run the core matching and classification on small, in-house language models. Postgres with vector search handles the semantic matching.
Expansion possibilities
Our model is deliberately narrow: candidate-side subscriptions. We offer a free Seeker tier, plus Candidate at $29/month and Contender at $49/month, with quarterly through annual billing options. This constitutes our revenue today. We have no ads and, critically, never sell candidate data. Jobric works for candidates because their interests come first. We prioritize this alignment in everything we build.
We started charging on May 1st, after running a free beta through March and April to stress-test match quality before asking anyone for a card. We currently have $3,300 MRR. Two months in, I won't pretend a dramatic growth curve exists yet, but I see early, durable paid conversion in a category everyone insists candidates won't pay for. Margins help: As a cloud architect by trade, I run a set of small language models in-house for high-volume work at a fixed cost of around $20/month, while only heavy reasoning hits a frontier model. My cost per match drops as I grow. Anyone running purely on third-party LLMs has the opposite problem.
Expansion moves in a few directions. The simplest direction involves upgrades: free to paid, and Candidate to Contender. Geography offers a larger expansion path: we launched in the US, UK, and Canada from day one instead of US-only. Europe is next. Each new market widens our audience at little added cost.
Segments represent the biggest opportunity. Jobric is built for everyone, not just tech. I've spent real time with universities, career coaches, and people in completely different fields to understand each group's struggles. This drives features for users nobody else serves: ghost and scam job detection, visa sponsorship filtering, and more are coming.
Churn presents an honest challenge, and it's baked in. If I do my job, you get a job, and then you don't need me. Retention and expansion become the same question: how do you stay valuable between searches? This thinking drives the biggest thing I'm building right now, which I'm not ready to detail yet. Without giving it away, it aims at people actively searching and those who already have a job but want to stay ahead in their career. If it lands, it transforms Jobric from a job-hunting tool into something you keep around all the time.
One piece of advice from all of this: charge before you feel comfortable. Free users tell you almost nothing. The day a stranger pays out of their own pocket for something they could get a worse version of for free, that's the only validation that counts. Everything before that is a hobby with traffic.
Educating the market on LinkedIn
LinkedIn has been the engine from day one. That's where Jobric's future users live, so when I needed beta testers, I went straight to the public and asked who wanted to try something new. That's how I attracted the first cohort, and it's still the main channel. I run it as a campaign, not random posts, and constantly tune it based on what resonates. One number I'm weirdly proud of: the business page crossed 100 followers in under a month, which is harder for a brand page to achieve than a personal profile.
Our own data powers much of the content. The same market intelligence that drives the matching informs what we publish, including a newsletter and blog we launched in June. Instead of guessing what to say, I use what Jobric sees about the job market, which makes the content both differentiated and quietly demonstrates the underlying product.
Research has shaped the channel strategy as much as the content. I've spent time talking to different segments, universities, and career coaches to understand not just how Jobric helps, but why it matters specifically to each group. I'm a "start with why" person, and the more I go back to why Jobric exists, the sharper the messaging becomes. This is driving a second-half push I expect to achieve far more than the first half did.
If I offer one piece of growth advice, it's that the hardest part isn't reach; it's reprogramming a reflex. Job boards, LinkedIn, and one-click-apply tools have trained everyone to believe that more equals better. More listings, more applications, more activity. Jobric is the opposite bet: fewer and better listings. So a key part of growth is convincing people that quality over quantity isn't just a nicer way to job hunt; it's the only one that respects their time.
Shift that belief, and the product sells itself. That's the marketing problem I'm solving.
Feedback and books
End-user feedback has been the single most valuable thing to me — and not just the positive kind. During the beta, we constantly asked for it. Most feedback was encouraging, with suggestions we baked straight into the product. But the angriest feedback stuck with me most.
One beta user told me, "You should pay me for my time because this is such a crap product." You can't please everyone, and we almost certainly lost that person for good. But I learned something important from it. A beta user only had to upload a resume and wait for jobs to come to them. No cost, no real effort on their end. So why were they so furious? Because Jobric's underlying promise actually matters to people. People don't get that angry about something they don't care about. People are exhausted by how job searching works today, and that reaction showed me I'm building something worth being angry about. It motivated me more than any compliment.
Another thing that helped was Simon Sinek's "Start With Why." That book has influenced me greatly lately. It keeps pulling me back to Jobric's true purpose — not the feature list, but why it exists, who it's for, and how to clearly explain that to someone who's never heard of it. When the day-to-day gets noisy, returning to the 'why' keeps decisions clean.
Focus, think, and really understand your product
My advice? Focus. Then focus more. I advise a handful of startups, and I see butterfly brain wrecking most of them. You know the kid or the puppy who spots a butterfly and chases it, then a second one drifts by, and they chase that one instead, and so on. That's how a startling number of founders operate now, and AI has made it worse, because you can chase every shiny idea instantly. The discipline to pick one problem and stay on it until you solve it has become rare, and it's the single biggest predictor of who makes progress.
Related to that: Think before you build. I'll ask a founder something basic like, "Walk me through your user's workflow: Where do you start and what are they trying to solve?" Instead of an answer, I get "Look at this cool mockup I made with Claude." People sprint straight to the solution, the demo, the visual, and skip sitting with the problem and asking hard questions first. You don't have to take every piece of advice, but you must think and do the research. The mockup is the easy part. Knowing why it should exist is the work.
Finally, and I mean this: Understand your own product. I talk to founders who built something with AI tools and can't answer basic questions about how their product works. It doesn't matter whether you're technical or not. If AI built it, use AI to interrogate it. Ask it what it made, why it chose those options, and where it's fragile. Being non-technical is not an excuse to be a stranger to your own product. Founders who can't explain what they built fall apart the first time something breaks.
What's next?
My biggest goal is for Jobric to become the first place anyone reaches for when they look for work. Not a job board they check, but the trust layer the whole search runs through. People are jaded, and AI has flooded everything with noise; job seekers lack something they can truly trust to be on their side. That's the position I want Jobric to hold.
Part of that involves refusing to accept things everyone else treats as normal. Consider salary numbers: our data shows only about 57% of postings carry real detail. Why is that acceptable? I can't force an employer to be honest, but I can make dishonesty stop working. If a posting hides the basics a person needs to make a real decision, Jobric can flag it, filter it, or surface what the employer left out, so these games quietly lose their power. The more the platform does that, the more it protects people instead of wasting their time.
Ultimately, the goal is simple and human. I want people to find work without getting lost in how fast everything changes, and to emerge with a job that truly fits and a bit of hope they didn't have going in. If Jobric reliably does that, at scale, across every kind of worker, then it will have achieved what I built it to do.
To see the product, start here. For market commentary and data behind much of what I discussed here, read our newsletter: The Update from Ric.
To follow along or reach out directly, I write regularly on LinkedIn: Jobric and personal. I'm genuinely easy to reach, so if anything here resonated, feel free to send a DM.
Leave a Comment
The reasons why you built are precisely the reasons that drove me to start building myself. I am encouraged by your progress and accomplishments! I do have one question though, as Beta testing was tough (and nerve-wracking for me).
How was your mindset as you were receiving feedback throughout that process? If wavering, how did you navigate it?
It was tough, no question. The biggest thing I kept telling myself, even before Beta, was that no single piece of feedback meant everything. One person saying it sucked didn't mean everyone thought that. And one person asking for a feature didn't mean I'd run off and build it.
I was looking for plenty of signal, not reacting to every voice.
My goal was two things: make sure what I built actually worked at a scale bigger than my own ad-hoc testing, and then figure out what to improve. A lot of the UI changes and how things are presented actually came straight from our Beta users.
The $20/month fixed-cost model hosting detail buried in here is the real technical insight most people will gloss over. You're essentially doing task-level routing — small in-house models handle high-volume matching work at near-zero marginal cost, and only the genuinely complex reasoning tasks touch a frontier model.
I've been tracking this pattern across about a dozen products. The ones that survive past year one almost always figured out this split early. The ones burning through API credits on every single operation — even the ones a 7B model could handle — typically hit a cost wall around month 4-5 that forces either a painful rewrite or a pricing increase their users won't accept.
The part about "cost per match drops as I grow" is the real moat here. Most AI-first products have the opposite economics — more users means more API calls means thinner margins. Your architecture inverts that. That's worth way more than any feature advantage because it compounds.
Curious about one thing: how much of your engineering time went into figuring out which tasks could safely run on the smaller models versus which ones genuinely needed frontier reasoning? In my experience that classification problem is where most of the iteration lives.
Honestly it was less about figuring out what I could safely run on smaller models, and more about what telemetry I could capture to build something of my own.
I spent a lot of time on research, both with AI and the old-fashioned way, actually reading the material myself, on how to fine-tune a model. The first question wasn't "which tasks need a frontier model," it was "CAN I even do this, or do I need insane GPU resources to pull it off?"
The more I dug into jobs and job postings, the more I realized the work was less high-level reasoning and more classification. And classification lends itself to smaller models.
So before we even opened Beta, I was recording everything , the decisions the AI made, the confidence levels, all of it. None of it is easy. But the goal was simple: I didn't want to ship another product that worked "ok." and I wanted a way to dramatically improve as I grow.
The line about charging before you feel comfortable really lands "free users tell you almost nothing" is such an underrated point. We're pre-launch on our own product and it's tempting to keep polishing before asking for money, but this is a good reminder that the real signal only shows up once someone's actually paying. Also really appreciated the honesty about churn being baked into the model — that's a hard thing to say out loud about your own product.
I really liked the part about charging before feeling ready. That stood out because many founders wait too long for perfect timing. The focus on solving one real problem instead of chasing every new idea also makes a lot of sense. Building trust with users seems like the biggest win here not just growing fast.
This is wild progress for two months while still working full-time, serious respect for the focus and execution here. Im really interested in:
1) Was there one distribution channel or tactic that clearly outperformed the rest, or was it a mix?
2) How are you protecting your energy now while juggling a job and a growing product?
3) If you had to start over, is there anything you’d not do again in those first two months?
Would love to hear more about how you’re thinking about the moment when this becomes your main thing, not a side project
What inspired you to build Jobric for job seekers instead of recruiters?
Hitting $3.3k MRR in just two months is impressive on its own, but doing it while holding down a full-time job is next-level. Balancing energy levels after a 9-to-5 is usually the hardest part of building a side project. How did you structure your weeks or days to avoid burnout while pushing this out so fast?
I've spent more than fifteen years in cloud and platform engineering, working up from sysadmin to VP-level cloud strategy. Along the way, I've built and led Cloud Centers of Excellence, run datacenter-to-cloud migrations that saved seven figures a year, and advised everyone from seed-stage startups to Fortune 100s. I'm currently a Senior Solutions Architect at Microsoft, and I build Jobric in my own time and with my own money. Most days run from 5am to 10pm.
The "charge before you feel comfortable" point hit hard, I've been hesitant about pushing harder on pricing precisely because free users seem so much easier to please. Your framing that free feedback tells you almost nothing, while one paying stranger tells you everything, is a good reset.
Also really appreciated the bit about understanding your own product even if you're non-technical. I built mine using AI tools without a coding background, and it's tempting to treat the "how it works" as a black box I don't need to fully grasp. Going to actually interrogate it the way you described instead of just shipping and hoping.
Impressive that you're doing 5am-10pm on top of a full-time role. Curious, now that you're at $3.3k MRR, does LinkedIn still feel like the main lever, or are other channels starting to pull weight too?
The fractional advisor model is underrated for solo technical founders. Most people think it's all-or-nothing — either you have a full co-founder or you figure it out alone. The CISO, general counsel, CFO, and exited founder setup you described is a much smarter middle path.
"Charge before you feel comfortable" is the line that sticks. Most people wait until the product feels finished, by which point they've spent months building for a price point they've never validated. Charging early is uncomfortable but it's actually the fastest way to find out if you've built something people genuinely value versus something they just find interesting.
Curious how much of the early traction came from your existing network vs. cold outreach — whether the Microsoft credibility opened doors or whether it was purely product-driven.
I hope I can reach there aswell
This is awesome. I feel like I am stuck in my current job and I just started a few months ago. I'd love something that helped me surface opportunities out there.
Congrats!
Great story—thanks for sharing your journey. I especially liked your focus on solving a real problem for candidates instead of employers. Your point about using engineering first and AI second really resonated with me. Wishing you and Jobric continued success. Looking forward to seeing how it evolves!
Congrats! One thing we've noticed is that early traction usually comes from talking to users much more than shipping features.
This is wiiiild. Such inspiring story. It's the 5am to 10pm work for me
Inspiring work! I look forward to watching Jobric grow and develop as it help people achieve goals and dreams
Erik, this is genuinely inspiring 🔥
Building something this solid for candidates (not recruiters) while pulling full-time Microsoft hours? Respect. Starting from helping someone you love who was burned out by the job hunt makes the whole story feel real and human.
Love the “engineering first, AI second” mindset and that early charging advice — super practical. Congrats on the $3.3k MRR in just two months, man. Keep going!
That's a solid turnaround on the LinkedIn outreach — curious how many messages you sent before getting enough beta testers to validate the concept?
The line that'll stick with me: "charge before you feel comfortable... everything before that is a hobby with traffic." That's the part most people skip, especially with AI making it so cheap to build something that looks finished. Free signups tell you people are mildly curious. A stranger's card getting charged tells you the thing is real.
Also worth noting he had a domain expert's unfair advantage going in — fifteen years in cloud let him keep infra costs near-zero and build his own small models instead of paying per-call to a frontier LLM. Most solo builders don't have that lever, so their margins and runway won't look like this even with a similar idea. Doesn't make the lessons less true, just means the economics here aren't fully replicable without that backgroun
Amazing Stuff!!
The "butterfly brain" framing is so accurate. I see this constantly with founders who are technically capable but keep restarting because something new came out.
Erik's point about charging before you're ready is one of the hardest lessons for people to actually internalize. Free users are friendly but they do not tell you much. A paying stranger telling you the product is broken is worth more than 100 encouraging beta testers.
The side project constraint is also interesting. Building with a full-time job forces you to be ruthless about what actually gets worked on. Some of the people who come to goldenweeks, our 2-week deep work retreat in Zanzibar, say the same thing in reverse: having unlimited time sounds great but without constraints they actually get less done. Erik's containerized, on-demand mindset translates well to unstructured time too.
Really solid story, congrats on the traction.
I admire how much you’ve accomplished while working a full-time job. Startups really need help from someone experienced like you. I’ve been studying the mindset of successful people, and I’ve realized that they stick to what works and never give up.
Really impressive execution in such a short time.
Love the shift from employer-centric to candidate-centric feels like a real wedge.
Reminds me of what we’re building with Flow Era, focusing on acting on intent in real time instead of just collecting data.
Great read. I especially liked the part about building for one person first and letting real feedback shape the product. I've been following a similar approach with my own project—starting from real user problems instead of chasing features. It's encouraging to see that disciplined focus can lead to meaningful growth. Congratulations on the milestone!
The line "charge before you feel comfortable" is the most practical advice I have read this week.
I launched my first Shopify app three days ago as a solo founder. No team, no funding. The app helps EU merchants comply with the European Accessibility Act using AI-generated alt text. I went straight to paid from day one — $19/month — because I knew free users would tell me nothing useful.
The butterfly brain warning also hit close to home. I caught myself this week wanting to add multilingual support, a PDF report feature, and email alerts — none of which my first customer has asked for. The discipline to stay narrow is harder than it sounds when you are building alone and every new idea feels urgent.
One thing that stood out most: you built Jobric for someone you love who was stuck in a draining job. My motivation was similar — I watched EU merchants panic about the accessibility law with no practical tool to help them. That emotional clarity about why you are building something is underrated as a filter for every decision that follows.
Genuinely impressive to hit $3.3k MRR in two months while working 5am to 10pm at Microsoft. That is a standard worth chasing.
Love this!!
Great success story! very clever to use the same data pipleline that does the matching to generate content for the website
This is impressive,
Hitting $3.3k MRR in just two months while working full-time at Microsoft is seriously inspiring. The focus on engineering first and AI second, plus charging early, seems to be paying off.
Thanks for sharing the journey — really motivating for other solo founders.
Very nice article, but the niche is not a vergin one: RippleMatch/Teal/Sorce are already offering something similar and Linkedin too is not so faraway and #can kill you with just a feature reease - have you taken this in consideration? which feature you offer is unique and not easily reproduce by the ( strong) competition?
the containerized on-demand architecture is genuinely smart for this problem shape. most people building job matching go straight to an always-on service with websockets and live-updating feeds, which is cool until you look at the infra bill. bursty matching work that queue-triggers, does its job, and sleeps again is exactly how you keep cost per match actually low instead of just claiming it.
the Postgres + vector search combo for semantic matching is also the right call at this stage imo. i've seen teams jump straight to a dedicated vector db like Pinecone or Weaviate and then realize they're paying for another managed service when pgvector handles the workload fine until you're at a scale where you'd have much bigger problems to worry about.
one thing i'm curious about: how are you handling the resume parsing normalization step? the "security officer interpreted as security guard" problem you mentioned is exactly the kind of thing that kills matching quality and its almost always a data problem upstream of the model. are you mapping titles to a taxonomy before scoring, or doing it contextually from the full resume text?
wow thats amazing. I'm starting, too, and hope I can get to your stage
Hitting $3.3k MRR in 60 days while holding a full-time job is a masterclass in leverage. I'm curious: what was the single most painful trade-off you made to maximize your velocity during those two months?
This is so inspiring for me. I love the business structure, and I have learnt a lot from you. Congratulations.
I really liked your point about using engineering first and AI second. It’s easy to focus on the AI layer, but the real value often comes from understanding the problem, structuring the data, and building reliable logic underneath it.
I’m also building a small Windows product, and your advice about staying focused, charging earlier, and understanding every part of the product really resonated with me.
I also liked the point about using engineering first and AI second.
It’s easy to assume every AI product is just another LLM wrapper, but a lot of the real differentiation comes from everything around the model: workflow, data, scoring, and product decisions.
Congrats on the progress!
good article thank you
Building is one part, how did you handle the marketing aspects of the product?
The churn line ("you get a job, you don't need me") is the whole business: you didn't build a subscription, you built a one-time purchase people cancel on success. The escape isn't a feature, it's repositioning from a "job search tool" bought during pain to a "career radar" nobody turns off, which flips billing from event-driven to always-on. Your alignment (candidate-paid, never sell data) plus a Microsoft-grade cost structure is the real moat, but candidate-pays also caps you to the slice frustrated enough to pay against free incumbents, so the growth question is widening who's willing to pay, not adding listings.
Building is one part, how did you handle the marketing aspect?
Great post—really clear breakdown of building and shipping alongside a full-time job. I especially liked the focus on iterating from real user feedback instead of overengineering early.
Curious, what was harder in the beginning: acquiring first users or validating resume improvement quality?
Two months to $3.3k MRR while working full-time means your positioning was tight from day one. Most side projects spend months iterating on messaging. Did you validate the positioning before building, or did you just get lucky with problem-solution fit? The speed suggests one or the other.
Impressive progress, especially while balancing a demanding full-time role. What stands out most is your focus on solving a real problem instead of chasing AI hype. Building around candidate needs and validating with paying users makes this milestone feel well earned.
Congrats Erik — $3.3k MRR in two months alongside a full-time job is seriously impressive. The LinkedIn beta-onboarding part is what jumped out at me. Were you cold-DMing people, or posting content and letting them come to you? And roughly how many beta testers did it take before the first ones converted to paying?
Solid execution doing this alongside a full-time job. Curious how you handled onboarding/auth for beta testers coming in from LinkedIn — did you build a simple invite-only flow or just open signups? I built a similar job-platform-style auth flow recently and the invite gating ended up mattering more for trust than I expected early on.
That's amazing! I'm 14 and just launched my first public project. Stories like yours keep me going. What was the hardest part in the first month?
The "charge before you feel comfortable" line is the one I'd underline for anyone reading this. Free users will tell you the product is great and then never come back. The first stranger who pays from their own pocket is the only signal that actually means something, everything before that really is just a hobby with traffic, like you said.
The LinkedIn point also tracks with what I've seen. Treating it as a campaign with a clear thesis, not a feed of "look what I built" posts, is the difference between a page that plateaus at a few hundred followers and one that compounds. Curious how much of your content calendar is planned in advance versus reacting to what's landing that week, since that balance is the part most people get wrong early on.
Also respect the call on churn being structural rather than a problem to solve away. Building toward "stay valuable between searches" instead of pretending you can stop people from ever needing you again is the more honest framing, and probably the harder product to build.
One thing that stood out to me was how much emphasis you put on understanding the problem before building the solution. I think many founders (myself included at times) get excited about features and forget to spend enough time talking to users.
I also liked your point about charging early. Free users can give feedback, but paying customers usually reveal whether you're actually solving a problem worth paying for.
Congrats on the early traction, and best of luck with Jobric. It'll be interesting to see how it grows over the next few months.
This is the first founder breakdown in a while where I stopped to take notes. The part about the $20/month fixed cost stuck with me more than the AI stuff. Everyone is out here burning API credits on every click, you're doing the opposite — small models for the boring high-volume work, frontier only when it actually needs reasoning. Cost per match going down as you grow is such a clean inversion of the usual SaaS death spiral.
Also appreciate the honesty on the angry beta user. I've had that exact "you should pay me for testing this crap" DM and it does mess with your head for a day. You're right though, indifference is worse. Anger means they actually wanted it to work.
The 5am to 10pm while holding a Microsoft architect role is wild, but the discipline part landed hardest — "butterfly brain" is real. I just killed two shiny features last week because of that same trap.
Congrats on the $3.3k. Charging before you're comfortable is scary, but it's the only signal that matters. Curious to see what the "between jobs" retention layer looks like. Rooting for you.
Really like that he used LinkedIn to onboard beta testers instead of waiting to build an audience first. Genuine question for anyone who's done this: did those hand-recruited LinkedIn testers actually convert into the paying $3.3k MRR, or did the paying customers end up coming from a different channel once the product was proven? A few weeks into building in public myself and trying to figure out whether early hand-recruited users become revenue or mostly serve as validation. Congrats to Erik either way.
Really inspiring journey. What stood out to me most wasn't the AI—it was the relentless focus on solving a real problem, validating with paying customers, and staying disciplined throughout the process. That's the kind of founder mindset that builds lasting products. Wishing Erik and the Jobric team continued success!
Hey Erik, huge congrats on hitting $3.3k MRR in just two months! Balancing this with a full-time VP-level tech job is seriously impressive. What really stood out to me was your approach to the architecture—specifically the "almost nothing runs all the time" mindset. Using small in-house models and on-demand containerized services to keep costs low is a brilliant moat. I strongly share that same "lean and zero-bloat" philosophy. In fact, it's the exact same core principle I used while building Zlvox.com. I wanted to create a fast suite of 25+ free developer tools (AI, JSON, PDF, etc.) completely free of heavy dependencies, focusing purely on speed and client-side performance.
Your point about charging before you feel comfortable is also spot on. When you first introduced the pricing tiers to the beta users, did you notice a lot of churn, or did the passionate feedback you received earlier give you the confidence that they were ready to convert?
Keep up the great work!
impressive
That's a really great insight
One of the best founder interviews I've read recently. My biggest takeaway wasn't the AI—it was the mindset: engineering first, AI second, and relentless focus on understanding the user's real workflow before building. I also liked the point about challenging industry assumptions ("candidates won't pay") with actual paid validation instead of accepting conventional wisdom. Congrats on the early traction, and thanks for sharing such a thoughtful behind-the-scenes look.
What you said about the angry beta user hit home. Someone who's indifferent just leaves — someone who's furious proves the problem is real. That's a useful reframe.
The "charge before you're comfortable" advice is something I'm living right now. I'm building a payment recovery tool for indie founders (flat $29/month, 5-minute setup — no enterprise pricing, no sales call). Same bet: people will pay for something that actually works for them, even in a space where the incumbents have trained the market to expect either free or expensive.
One question: how did you handle the first 10–20 paying conversions from beta to paid? Did you reach out personally or let them self-convert? Curious how much hand-holding was involved before it felt like real organic traction.
Both, but personal first. I reached out to everyone individually, and we also sent a big thank-you along with a 50% discount code good for the rest of the year.
The thinking was simple: this product is for the people, so the last thing I wanted to do was oversell to the exact group that helped me build it. A lot of them weren't in immediate need of a job either. So rather than push, we kept the door open, if they ever do need it, they can come back and sign up at a discount they more than earned.
Hello everyone! Building YOUTH X – looking to connect with fellow builders
Hi everyone,
I'm Haider Pasha, and I'm currently building YOUTH X, a platform focused on empowering young founders and helping them grow their startups.
I've been exploring the Indie Hackers community and have found the success stories here very inspiring. I'm at the stage of building my MVP and would love to connect with others who are also on their startup journey.
If you're building in the EdTech or community space, or just want to chat about the challenges of early-stage growth, feel free to reach out!
Looking forward to being an active part of this community.
The "almost nothing runs all the time" architecture is the part that stood out most to me. I've been deep in scheduling/uptime infra lately — most of what I build needs a process that stays alive continuously to track state between runs, so on-demand containers that wake up and go quiet isn't a constraint I usually get to use. Curious how you handle state that needs to persist across two queue-triggered runs — e.g. a candidate's "what's changed since their last scan" — without something always-on holding onto it between triggers. Is that living in Postgres between invocations, or somewhere else?
Yeah, the database is exactly where that state lives. The "what's changed since last scan" diff gets persisted there between invocations, nothing always-on needed to hold it.
Two things pushed me toward on-demand. First, I started fully self-funded out of my own savings, so I wanted to be as cheap as I possibly could and see how far that constraint could take me. Second, the nature of the work lent itself to it: checking for jobs, scoring fit, and so on isn't something a user sits and clicks through manually. The whole point is to take load off the job seeker. So the work is naturally bursty and queue-triggered, not continuous.
I got lucky that the problem shape matched the cheap architecture.
That tracks — bursty, queue-triggered work and on-demand containers are a clean fit. Mine's the inverse shape: I'm building GoBeep, a monitor that has to notice when a job didn't run, so there's no event to trigger off of — the checker itself has to keep existing between checks just to ask "did this fire when it should have?" That's what ruled out serverless for me even though it would've been cheaper. Interesting how the same "something happens on a schedule" problem splits into opposite architectures depending on which side of the trigger you're solving for.
All job platforms on the market are built from employers’ perspectives. Job seekers are the ones who genuinely need more support, so it’s amazing that you’ve built a product centered entirely on candidates. Keep up the great work!
Thanks, that means a lot. That's exactly the gap we're trying to close, the whole market is built for employers, and the people who actually need the help have the least built for them. If we can make even a few people feel less stuck and less jaded, that's the win.
Excellent breakdown of the execution and thinking. A few things stood out:
The focus insight is powerful - "butterfly brain" founders chasing every AI feature while you stayed on one problem. In an era where LLM-wrapping is trivial, that discipline is what separates products from toys.
Also impressed by the inverted approach - engineering first, AI second. You could have fine-tuned a model on resumes, but spent months understanding the actual hard problem (job description inconsistency, title lying, semantic mismatch). That payload problem matters more than the model.
The earned monetization validates quietly too. Charging before comfort, stress-testing on free beta first - opposite of "move fast/break things" but got you real paid customers in 2 months. Real signal vs vanity metrics.
One thought on retention - I'd be curious how the second half push (staying valuable between searches) lands. The "trust layer" positioning is strong if you can solve that.
Thanks for the sharp breakdown. You hit the nail on the head.
"Engineering first, AI second" is exactly how we keep costs down and match quality up LLMs are great, but they can't fix bad data engineering.
As for retention, building that "between searches" trust layer is the ultimate challenge when your product is designed to be outgrown. We're testing some things now to make it a career partner, not just a job-hunting tool.
Appreciate the validation on the slow, disciplined approach over the "move fast" noise!
You nailed the part that keeps me up at night. The first version of any product like this is built for the active search, but the real value is staying useful when someone isn't looking yet.
That's exactly where the next phase is pointed: making Jobric worth keeping around for anyone who's working and wants a leg up, not just people in an active search. The "trust layer" only works if it's earning its place between searches, not just during them.
More to come on that soon. Appreciate you seeing the thread that early, that's the half most people miss.
This comment was deleted a month ago