futurole

Go From Job Search to Job Offer

Visit Website
September 5, 2026 I Built an AI Job Search Copilot. Here’s What I Got Wrong.

I started building Futurole because I thought job searching was too fragmented.

You find a job on one website, tailor your resume somewhere else, look for the recruiter on LinkedIn, write a cover letter, and then try to remember which companies you applied to.

I thought AI could bring all of that together.

So I built a SaaS.

And then I discovered that building the product was probably the easiest part.

What I built

Futurole is an AI job search copilot.

The idea is simple: help job seekers go from finding a job to applying for it, with less repetitive work.

The product includes things like:

  • Resume tailoring

  • ATS checks

  • Recruiter discovery

  • Job tracking

  • Resume building

  • LinkedIn optimization

  • AI-assisted applications

I also built a Chrome extension because I wanted the experience to happen where people were already searching for jobs.

Technically, it is a mix of a web application, a browser extension, AI features, and a database of job opportunities.

Nothing particularly revolutionary.

But I thought putting all these things together would be enough.

It wasn't.

The first mistake: building too much

My first instinct was to build a complete job search platform.

More features meant more value, right?

Not necessarily.

The problem is that every feature creates another thing to explain, maintain, and improve.

A user who only wants help tailoring their resume does not necessarily care about recruiter discovery, job tracking, or a resume builder.

I was trying to solve the entire job search.

The user might only have wanted help with one annoying task.

That distinction matters.

The second mistake: making people pay before they understand the product

At one point, Futurole had no free tier.

Users had to pay to use the product.

I understand why I did it. I wanted to avoid building something that people would use for free forever without generating revenue.

But I think I underestimated how difficult it is to convince someone to pay for a product they have never used.

Especially when the product is supposed to help them get a job.

Job seekers are already dealing with enough uncertainty.

Asking them to pay before they understand whether the product is useful adds another obstacle.

I eventually brought back a free plan.

I don't know yet if it is the right long-term pricing strategy.

But I think it is a better way to let people experience the product before asking them to pay.

The third mistake: confusing traffic with progress

I have spent a lot of time thinking about marketing.

SEO, backlinks, social media, product directories, content, and everything else that comes with trying to get people to discover a SaaS.

At one point, I was looking at traffic and thinking:

"If I can just get more people to the website, things will start working."

But traffic is not the same as progress.

For example, Futurole had around 784 visits in one month.

That sounds encouraging.

But when I looked closer, most of the traffic was direct.

Google brought around 115 visits.

LinkedIn brought 8.

Reddit brought 15.

The numbers were a reminder that getting people to visit a website is not the same as getting them to understand the product.

And getting them to understand the product is not the same as getting them to pay.

The fourth mistake: changing the landing page too often

I have changed Futurole's title more times than I would like to admit.

At one point, I changed it 77 times in five months.

I kept thinking that maybe the next headline would be the one that finally made everything click.

Some changes were probably useful.

Others were just me trying to fix a problem without really understanding it.

I think there is a difference between improving your positioning and constantly searching for a magic sentence.

A better headline can help.

But it cannot compensate for a product that does not solve a clear problem for a specific person.

What I am focusing on now

I am trying to make Futurole smaller.

Not necessarily smaller in terms of code.

Smaller in terms of the problem it solves.

Instead of asking:

"How can I build the best AI job search platform?"

I am trying to ask:

"What is one annoying problem that job seekers would genuinely pay to solve?"

That question is much harder.

But I think it is the right one.

I am also paying more attention to onboarding.

At one point, I had 33 new users in a week, but only 19 completed a scan.

That was a useful reminder that getting someone to sign up is only the beginning.

If they cannot understand what to do next, the rest of the product does not matter much.

What I would do differently

If I started again, I would probably:

  1. Pick one very specific problem.

  2. Talk to more potential users before building.

  3. Build the smallest useful version.

  4. Let people try it before asking them to pay.

  5. Spend less time changing the landing page.

  6. Focus on one acquisition channel instead of trying everything.

  7. Measure whether users actually get value, not just whether they visit.

I am still learning most of these things the hard way.

The part I am still trying to figure out

I don't think the answer is necessarily to build less.

I think the answer is to build something that is easier to understand.

A product can have 20 features and still feel simple if the user knows exactly what problem it solves.

A product can have 3 features and still feel complicated if the user has to figure out why they need it.

That is probably the biggest lesson I have learned from building Futurole so far.

I am still working on it.

But I am becoming much more interested in solving one problem really well than in building a complete platform.

For those of you building SaaS products: how did you decide which features to remove or stop building?

5 Comments

  1. 2
    The 33 signups vs 19 completed scans is interesting, but I’d look one step further: among those 19, what behavior tells you which part of Futurole is actually worth keeping? That seems more useful than deciding based on which features feel excessive.
    1. 1

      That’s a good point. I think Rezi is a great example of this.

      They built a relatively simple product around one clear problem: helping people create better resumes. Yet they’ve grown to millions of users.

      It makes me question whether I should really be trying to build a complete job search copilot.

      Maybe the better approach is to find one thing users already care about, make it really good, and let the rest come later.

      I’m going to look more closely at what those 19 users actually do after their scans. That might tell me more than any feature roadmap.

      1. 1

        That’s the right place to look — especially what users do after the scan rather than what the full copilot can theoretically offer. I’d be interested in digging into what you find from those 19 users. Happy to continue privately — what’s the best email to reach you on?

        1. 1

          Sure.
          contact@futurole. com

          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.

About

I’m building Futurole because I think job searching is still far more complicated than it needs to be. Finding a job is not just about finding an interesting position. You also have to show up everyday