Before building Jobsolv's AI platform, Atticus Li offered a done-for-you service at $2,000–$3,000 per client. In founder-maintained records, 24 of 26 clients received at least one interview within 30 days of signup. This was a small, selected, first-party cohort with no comparison group or external audit; it supported the decision to keep building but does not establish a causal lift over applying independently.
Why I Didn't Build the Product First
Every founder I talk to wants to start with the product. They have a vision for the platform, they've sketched the UI, they've picked their tech stack. They want to build.
I get it. Building is more fun than selling. But building before validating is how most startups die — not because the product was bad, but because nobody wanted it enough to pay for it.
When I started Jobsolv, the hypothesis was simple: job seekers were wasting enormous amounts of time applying to jobs they weren't qualified for, with resumes that didn't match the role. An AI platform that automated tailored applications could solve both problems.
But that hypothesis had assumptions I needed to test. Would people pay for this? How much? Would the results actually be good enough to justify the price? What specific outcomes did customers care about — more interviews, better companies, faster offers?
The cheapest and fastest way to answer those questions wasn't to build software. It was to do the work by hand.
The Done-for-You Phase
I launched what I called the Jobsolv Signature Service. High-touch, completely manual, and priced accordingly: $2,000-$3,000 per client.
For that price, clients got a full service: resume rewrite optimized for ATS systems, cover letter templates, targeted job search, and tailored applications submitted on their behalf. I did the work myself initially, then brought on help as demand grew.
The pricing was deliberate. I didn't want bargain hunters. I wanted people who were serious enough about their job search to invest real money, because those were the people who would give me honest feedback and who would represent the kind of customer the SaaS product would eventually need to satisfy.
Over the course of the services phase, I worked with 26 clients. The records provided useful demand and outcome evidence, with important limits.
24 of 26 clients (92.3%) received at least one interview within 30 days of signup. The denominator includes the 26 service clients in this founder-reported cohort. “Success” here means at least one interview; it does not mean a job offer, accepted role, or improvement versus an untreated baseline.
The result was strong enough to justify further product work, but there was no contemporaneous control group, so it should not be described as an improvement over a general job-seeker baseline.
What I Learned From 26 Clients
The services phase wasn't just about validation. It was about learning things that I couldn't have learned from market research or customer surveys.
Learning 1: The resume isn't the bottleneck — targeting is. Most clients came to me thinking their resume was the problem. And their resumes usually did need work. But the bigger issue was that they were applying to the wrong jobs. They were spray-and-pray applying to hundreds of positions, most of which they weren't qualified for. When I targeted their applications to roles that matched their actual experience and skills, interview rates went up dramatically — sometimes before I even rewrote the resume.
This insight shaped the entire Jobsolv product architecture. The AI doesn't just fix your resume. It matches you to jobs where you're genuinely competitive and tailors each application to the specific role.
Learning 2: A premium-priced service found paying customers. Twenty-six clients bought at $2,000–$3,000, generating approximately $58K+ in founder-reported services revenue before the software launch. That demonstrates willingness to pay in this cohort without claiming an unsupported market-rate multiple.
Learning 3: The process has repeatable patterns. After working with 26 clients manually, I could see exactly which steps were formulaic (ATS optimization, keyword matching, format compliance) and which required human judgment (career narrative positioning, industry-specific language). The formulaic steps were automatable. The judgment calls could be augmented by AI but might still need human review for premium tiers.
This decomposition — understanding which parts of the service were mechanical and which were creative — was the blueprint for the SaaS product's feature set.
The Transition to Product
With 26 paying clients, 24 receiving an interview within the defined window, and approximately $58K+ in first-party services revenue, I had enough evidence to justify the next build stage. The cohort was directional product evidence, not a randomized validation study.
Jobsolv launched as a SaaS platform in March 2024. The initial product automated the targeting and resume tailoring that I'd been doing by hand, using AI to match candidates to suitable roles and customize their applications.
First-party product records later showed:
- 304 users at launch — mostly from the services client network and their referrals
- 8,233 cumulative users within six months — first-party count; no constant month-over-month rate claimed without the monthly series and calculation method
- 35,000+ users by July 2026 — founder-reported; current paid user-acquisition spend was $0 at the measurement date after earlier paid tests were stopped, which is not $0 operating cost
I wrote about the Jobsolv paid-acquisition snapshot in detail. The service phase informed the product and positioning; it did not, by itself, prove that the software caused the later growth.
Building the Team
Scaling from a services operation to a SaaS platform required a team I did not have. Jobsolv used a 27-person cross-functional roster across the build, with up to 22 active in a week. Building and managing that distributed roster was its own education.
The development team was a 3-5 person agency based in Egypt. I chose an agency over individual contractors because I needed a team that could handle sprint planning, code reviews, and coordinated delivery without me managing each person individually. The agency model gave me a technical lead and a team structure without the overhead of recruiting and onboarding individual developers.
The design team was a separate UX/UI agency. Separating design from development was intentional — I wanted design decisions driven by user research and usability testing, not by what was easiest to implement. Having an independent design team created healthy tension between "what's the ideal experience" and "what's feasible to build this sprint."
Freelancers from Upwork and Fiverr handled specialized tasks: content writing, customer support, data labeling for AI training, and marketing collateral. The gig economy gets a lot of criticism, but for a bootstrapped startup, it's an incredibly efficient way to access specialized skills without permanent headcount commitments.
What I Learned About Hiring Remote Talent
Managing a distributed team across multiple agencies, time zones, and engagement models taught me things that no management book covers.
Evaluating portfolios is necessary but insufficient. A beautiful portfolio tells you someone can do good work under ideal conditions. It doesn't tell you whether they can meet deadlines, communicate proactively about blockers, or handle feedback without getting defensive. I learned to weight the trial project more heavily than the portfolio — a paid two-week engagement on a real deliverable reveals more than any number of case studies.
Fixed-price vs. hourly contracts depends on scope clarity. For well-defined deliverables (design a landing page, build this API endpoint), fixed-price contracts align incentives. For exploratory or evolving work (iterate on onboarding flow, debug performance issues), hourly contracts are more honest. I used both, depending on the task.
Milestone payments protect both sides. For larger projects, I structured payments around deliverable milestones rather than time periods. This gave the contractor clear targets and gave me natural checkpoints to evaluate progress and course-correct if needed.
Resolving performance issues quickly is a kindness, not a cruelty. Early in the Jobsolv build, I let underperformance persist too long because I didn't want to have difficult conversations. That's a mistake. The contractor knows they're struggling. The rest of the team knows. Addressing it directly — with specific examples, clear expectations, and a defined improvement timeline — is more respectful than letting it fester.
Product-Led Growth After Launch
The services-to-SaaS transition changed the delivery model and expanded self-serve access. A separate audited comparison would be required to claim a specific cost reduction or that the software reproduced the service cohort's outcome rate.
The numbers tell the story:
- 35K+ users — founder-reported July 2026 milestone; first-party acquisition records associate growth with referrals, SEO, content, directories, and community work but do not isolate their causal contribution
- $80K+ total revenue — combining services revenue and SaaS subscriptions
- $0 current paid user-acquisition spend — July 2026 snapshot, not lifetime zero spend and not a fully loaded CPA; earlier paid tests were stopped
- Outcome evidence remains limited — Jobsolv does not currently publish an externally audited candidate job-placement rate or a causal comparison against applying without the product
The cost boundary is worth emphasizing. When I experimented with paid acquisition early on, the observed unit economics did not justify continuing it for a bootstrapped company. The paid-acquisition snapshot post explains why $0 media spend is not $0 acquisition cost. The services revenue supported the next build stage; the later acquisition record does not isolate product quality as the cause of organic growth.
The Validation Framework
If I were advising another founder on validating a SaaS idea, here's the framework I'd recommend based on the Jobsolv experience:
Step 1: Sell the service manually. Don't build anything. Offer to do the thing your product will eventually do, by hand, for individual clients. Charge a premium price — you're testing willingness to pay, and low prices attract low-signal customers.
Step 2: Track outcomes explicitly. In the selected first-party cohort, 24 of 26 clients received at least one interview within 30 days. I tracked time to first interview and the approaches used, while preserving the limits: there was no comparison group, and the outcome was not an offer, accepted role, or causal lift.
Step 3: Identify the automatable patterns. After serving enough clients manually, you'll see which steps are repeatable and mechanical (automate these first) and which require genuine expertise (these become your AI-augmented features or your premium tier).
Step 4: Build the minimum product that tests the service insight. Define the product outcome separately and measure it in the software cohort. Do not assume a self-serve product will reproduce a selected, high-touch service cohort’s results.
Step 5: Invite service clients into the launch cohort. Prior clients can provide informed feedback and referrals, but participation and product outcomes still need to be measured rather than assumed.
What I'd Do Differently
The services phase was unequivocally the right call. But I'd change a few things in execution.
I'd consider a larger and more diverse cohort while preserving a price that tests real willingness to pay. More clients would narrow descriptive uncertainty and expose more use cases, but without a comparison group it still would not establish causal efficacy.
I'd formalize the feedback loop earlier. I collected client feedback informally, but I should have structured it into a systematic research process from the first client. The informal feedback was useful but biased toward whatever the most recent client mentioned.
I'd also move faster on the transition. The services phase ran longer than it needed to because I was reluctant to commit to building the product until I felt absolutely certain. In hindsight, I had enough validation after 15-20 clients. The last 6-10 were confirmation, not discovery.
The Bigger Picture
The Jobsolv journey — from manual services to validated SaaS — connects to everything I believe about building products and running experiments. At NRG, I test hypotheses about customer behavior through A/B tests. At Jobsolv, I tested a business hypothesis through a services-first model. The methodology is different, but the principle is the same: validate before you invest.
This is core to Atticus Li's PRISM Method. Whether you're testing a new enrollment flow or testing a new business model, the discipline is the same: define the hypothesis, design the measurement, execute the test, interpret the results honestly, and let the data guide the next decision.
Jobsolv exists because the services phase produced enough first-party evidence to justify the next investment. The later 35K+ user count is another founder-reported milestone, not proof that every customer will achieve the service cohort's outcome.
_Building something and thinking about the services-to-SaaS path? Reach me at atticus@atticusli.com._
FAQ
What did the services phase validate?
It provided a founder-reported cohort in which 24 of 26 clients received at least one interview within 30 days. It validated enough demand and workflow detail to justify further investment, not a universal customer outcome.
Why not build the software first?
Services exposed the user's job, operational steps, edge cases, and willingness to engage before a larger engineering commitment.
How should another founder use a service cohort?
Publish the denominator, eligibility, outcome definition, time window, and missing follow-up. Then decide which parts of the workflow are stable enough to productize. The UK Government's service-design guidance and user-research guidance offer useful process checks.