The background

JobMatcha is my first attempt at a full-stack website. It came about in January 2025 when I was moving to Australia. I quit my job in New Zealand and was looking for something new.

I found the whole process needlessly manual. I knew what I wanted, but I couldn’t effectively filter jobs based on that. A lot of the important information was only available when reading the whole job advert.

I liken it to Tinder – imagine if, instead of Tinder matches, you were provided with random profiles and had to search each one to see if you were really a match. You probably wouldn't use it for very long.

Searching for job matches in JobMatcha

I wanted job matches that came to me, and so, JobMatcha was born. You input your experience and what you’re looking for; it scrapes Seek, reads the job ads, and matches against your input.

A job match. You can click the seek logo to apply

The technical

Once I had it working locally, I needed to make it accessible to others. I had never worked on any real front-end, so I did what any good back-end engineer does and served my front-end from my back-end API:

An overview of the architecture

I got a domain name (jobmatcha.org), hosted it on Digital Ocean (for about five dollars a month), and hooked it up to GitHub so that it would automatically update whenever I publish code changes.

The learnings

Ultimately, this was a learning exercise. I wanted to go through the motions of making a product to give myself a baseline understanding, and to feel some of the pain that motivates a better approach.

The good

I learned a lot, in particular:

• How to get a domain, organise hosting, and deployment
• More JavaScript, CSS, and HTML
• API best practices when supporting a front-end

Some things I think worked out well:

• Used a lot of generative AI-enhanced workflows for the front-end code
• Nice colours and branding

The bad

Building on top of an unsupported API is not very smart – every time Seek updates their front-end my service breaks. This removes any possibility of monetisation in the future as no-one is willing to pay for a product that breaks often and without warning (except for GCP customers).

The actual product was not great when using it more than once. Each time you opened it you needed to fill out your details again.

I didn’t do enough research into what the incumbent platforms were capable of: most of the “advanced search” use cases are already covered by Seek’s existing search system.

Some other things:

• It has high costs that scale with usage
• Designing a product as I’m building it is hard

For next time

Next time I want to apply my learnings to make something useful that I can monetise. My goal with my next project is to get a single paying customer.

I will implement directed research and design prior to building.

Things to research:

• Market size
• Competition
• Ability to scale
• Monetisation
• How to reach users
• Is there a network effect involved?

Things to design:

• User journey
• Wireframes

I want to improve my technical stack for anything more complex. I can’t avoid front-end development forever. Next time I’ll use a front-end framework such as Next.js. I’ll also use Stripe to build in the monetisation.

Overall it was a great project and I learned a lot. It showed me where my knowledge is lacking, and some of the barriers that are not obvious when you get started (unless you do the research!).