Søknadsbasen: the tool I couldn't find, so I built it myself

Søknadsbasen started with irritation.

I've been job hunting a couple of times, and every time I've ended up with the same mess: a folder of half-finished CV files, a spreadsheet of application statuses that's out of date after three days, and a list of contacts I can't keep track of. There are plenty of tools for this, but most of them are either too simple to be useful, or so packed with features that they require an onboarding process just to send a single application.

I wanted something in between. Something I would actually open.

So I built it myself.

The problem with existing tools

Most job search tools think of job hunting as a list. You add a position, set a status, maybe jot down a note. That's fine for the first few weeks. After a month of active searching you have fifty rows in that list, and you've lost the context on most of them.

What I was missing was a way to think about job hunting as something more structured, an ongoing process with phases, not just a register of what you've submitted.

What I ended up calling "job search sessions" was really this: that a job search period is its own object in the system. It has a start, it has a goal, it has associated applications, and it has an outcome. That lets you look at a single application in the context of the whole period it belonged to, not detached from everything else.

It might sound complicated, but it's intuitive once you use it. It's simply the right level of abstraction for the problem.

Building for yourself is a different exercise

I'm used to building for clients, or for users I never meet. That's a kind of discipline: you have to make things explicit, you have to write onboarding, you have to help someone who doesn't know the code understand what the button does.

Building for myself opened up shortcuts that were tempting and dangerous at the same time.

The positive version: I didn't need to build everything. I didn't need an admin panel to edit data, I could just go into the database. I didn't need a fancy onboarding flow, I already knew how things worked. That saved me a lot of time on things that didn't matter.

The negative version: I put too much implicit knowledge into the product. Functionality that makes sense to me, but that wouldn't make sense to anyone else. That's not a problem right now, but it's a limitation if I ever want to let others use it.

The lesson: build for yourself with a clear awareness of what breadth you're sacrificing. It's a deliberate choice, not a bug.

The CV builder is the hardest part

A job application tracker is really just a database with an interface. It's not trivial, but it's logical.

A CV builder is something else entirely.

CVs have opinions about everything. Font choices send signals about industry and seniority. Layout hierarchy affects what the recruiter sees in the first three seconds. What you include and what you leave out are editorial choices, not just filling in fields.

I spent far more time on the CV part than I expected. Not on the technical implementation, but on thinking through what a CV tool should actually help you with. Is it making the CV look pretty? Is it helping you choose what to include? Is it generating text?

I landed on control and predictability being the most important things. The exported PDF should look exactly like the preview. Changes should be reflected immediately. You should never wonder whether what you see is what the recruiter sees.

That's a lower ambition than "AI-generated CV tailored to the position", but it's something I actually trust.

Technical choices I'm happy with

Next.js and Supabase are my defaults now, and they worked fine here too. It's not exciting to write about, but that's the point: default choices that work let you spend your energy on the product, not on infrastructure.

Two choices I'm especially happy with:

Modeling job search sessions as a first-class model in the schema, not just as a tag or a status on the application. That gave me query capabilities I hadn't thought about when I designed it, and it made it natural to show aggregated statistics per session.

Letting PDF generation happen server-side. I considered client-side PDF generation for a long time because it's easier to set up. But server-side gives consistent rendering regardless of browser, and that's worth the complexity for something that's the core of the product.

What I underestimated

File handling is always more complicated than it looks. I wanted to let users upload a profile picture for their CV, and I estimated half an hour for the setup. It took a day and three rewrites, and I'm still not a hundred percent happy with the flow.

That's nothing unusual in itself. What surprised me was that I underestimated it even after having done it before. Something about file handling can't be fully taught, it's something you have to meet anew in the context of this exact project.

I also underestimated how much time I would spend designing the CV template itself. Technically it isn't hard. Aesthetically it's infinitely tweakable. I set myself a hard stop rule after the third iteration: this is good enough, not good enough to be distracting.

What I would have done differently

Built more of the admin panel earlier. I edited directly in Supabase at the start, exactly as I learned from the Klink project, and forgot the lesson anyway.

Decided on a PDF library on day one. I switched between three alternatives and lost time on every transition. Next time I'll sit down and evaluate properly once, not iterate through them in production.

Been clearer about what the product is not. Without that boundary, scope is open at both ends, and that's expensive.

Why it was worth it

Søknadsbasen is not a big product. It's a small tool that helps one person, me, keep track of something that otherwise creates friction.

But it was the first time I built something I actually used actively while building it. That gives a different kind of feedback than looking at analytics or reading user reports. You feel it in your body when something doesn't work well enough, because you're frustrated by it yourself.

It's a luxury most product developers don't have, being your own most demanding user. I try to carry that lesson into other projects too: understand the user's frustration so well that you feel it yourself.

Søknadsbasen lives at søknadsbasen.no. It's not ready for the general public yet, but that's where it's headed.