I'll be honest from the start: job hunting in Australia has been slower than I expected.
I'm a .NET and AI engineer with more than six years of experience across fintech, insurance and aviation. I've built APIs that move money, systems that process insurance claims, and lately a lot of work around GenAI, RAG and agents. I know what I can do.
But a job search doesn't run on what you know you can do. It runs on what someone can see in a few seconds. And for a while, I was sending application after application and getting very little back. Some were rejections. Most were just silence.
At some point I had to ask myself a simple question: if the inbox is quiet, what can I control?
I can't control how many people apply for the same role. I can't control whether a recruiter spends six seconds or sixty on my CV. I can't control the market.
But I can control what I build, how well I build it, and whether anyone can see it.
So that's what I've been doing. This post is about that decision, what came out of it, and what I've learned along the way.
Why build in public
A CV is a list of claims. "Experienced with CI/CD." "Built MCP integrations." "Strong in multi-tenant architecture." Every senior developer's CV says something like that, and a recruiter has no real way to tell which ones are true.
A live website, a working server and a written explanation of how I built them are different. They're proof. Anyone can click a link and see for themselves.
Building in public also does a few things for me personally:
- It keeps my skills sharp. Between applications and interviews, it's easy to drift. Building something every week keeps me writing real code and solving real problems, not just reading about them.
- It gives me stories. When an interviewer asks "tell me about something you built recently", I don't have to dig into a project from two years ago at a company I can't talk much about. I can talk about what I built last week, in detail, because I wrote about it.
- It makes progress visible. Job hunting can feel like nothing is moving. A list of finished projects proves to me that things are moving, even when the replies aren't.
- It shows how I think, not just what I know. A blog post shows the decisions, the trade-offs and the mistakes. That's much closer to what a team actually wants to know about a senior engineer.
What I've built so far
Here's what has come out of this period. None of it is a tutorial project. Each one is something I actually use, run or am actively building.
ShiftTracko: a multi-tenant SaaS for employee and tradie management
This is the biggest thing I'm working on, and it's been in active development since August 2025.
ShiftTracko is a SaaS platform for managing employees and tradies. The idea is simple: businesses that run on shifts and jobs need one place to manage their people. But the way it's built is where it gets interesting.
It's multi-tenant and multi-domain. That means one platform serves many separate businesses, each with its own space, and each can be reached through its own domain. From the outside, every business feels like it has its own app. Underneath, it's one codebase and one deployment.
The stack:
- ASP.NET Core Web API as the backend, where the business logic lives.
- ASP.NET Core MVC as the frontend.
- OAuth for authentication.
I chose to separate the API from the frontend on purpose. It keeps the core logic in one place, and it leaves the door open for other clients later, like a mobile app, without rewriting anything.
Multi-tenancy is one of those things that sounds easy in a sentence and gets hard very quickly. You have to think about it in every layer:
- Who is this request for? Every request has to be tied to the right tenant, whether it arrives on one domain or another.
- Data isolation. One business must never, ever see another business's data. That's not a feature, it's the foundation. A single missed filter in a query is a serious bug.
- Authentication across tenants. A user logs in through OAuth, but they belong to a specific business, with specific permissions inside it.
- Configuration per tenant. Different businesses want different settings, branding and rules, without the code turning into a pile of if-statements.
These are exactly the problems I solved at work in fintech and insurance, where getting data boundaries wrong isn't an option. Building ShiftTracko on my own means I own every one of those decisions end to end, from the database to the domain names.
I'm also building it with AI tools, mainly Cursor and Claude. Not to write the app for me, but as a fast pair programmer: scaffolding, reviewing, exploring options, and catching things I'd miss at 11 pm. It's changed how fast I can move as a solo developer, and it's taught me a lot about where AI helps and where you still need to slow down and think for yourself. (I wrote more about that in AI Isn't Replacing .NET Developers. It's Changing What Our Job Is.)
ShiftTracko is still in progress, and I'll write more detailed posts about specific parts of it, like how tenant resolution works, as it matures.
My own homelab
To run my projects, I turned a small Minisforum MS-A2 mini PC into a Proxmox server with separate production, testing and miscellaneous VMs. It runs 24/7, boots itself after a power cut, and every VM is hardened the same way.
The interesting part was the networking. My server has no static IP and no open ports on my router, but I can reach it from anywhere, and my public apps are on the internet with HTTPS. Tailscale handles my private access, and Cloudflare Tunnel handles the public side.
It's also given me a proper production / testing split for everything I build, which is exactly how I'd want a real team to work.
- No Static IP, No Open Ports: How Tailscale and Cloudflare Tunnel Run My Homelab
- From Windows 11 to Proxmox: How I Set Up My Minisforum MS-A2 Homelab
My own MCP server
I built an MCP server in .NET that sits on top of my own app: an interview question bank for senior .NET roles, and this blog.
That means I can talk to my app through Claude. I can ask it to find weak spots in my interview preparation, add new questions with full answers and follow-ups, or draft and manage blog posts, and it works through my own API with my own rules. It runs in two environments, UAT and production, just like a real product.
It started as a way to prepare for interviews. It turned into the best hands-on lesson in AI agents and tool design I've had. Designing tools that an AI uses well is a different skill from designing an API for a human developer, and I didn't appreciate that until I did it.
Deployments I don't touch
For years, I deployed by publishing from my machine and copying files to a server. Now every change goes through GitHub Actions: build, test, publish, deploy. Testing first, then production. I haven't manually copied a file to a server in a long time.
AI in .NET, for free
I also wrote about adding AI features to a .NET app without paying for every token, using tools like Ollama, NVIDIA's free models and a simple RAG setup. It's the kind of thing I'd want to know if I were on a .NET team trying AI for the first time.
My Master's capstone
Alongside all this, I'm finishing a Master of IT, and my capstone is a school transport and guardian tracking app. It's a good reminder that real-world problems (safety, privacy, and users who aren't technical) are often harder than any technical choice.
How I choose what to build
With limited time, I can't build everything. So I've ended up with a few simple rules:
1. Build something I'll actually use. The homelab hosts my apps. The MCP server runs my blog and my interview prep. If I use it every day, I find the rough edges, and I keep improving it.
2. Build close to the roles I want. I'm applying for .NET and AI engineering roles, so I build with ASP.NET Core, real authentication, real deployments and real AI integrations. A project in a stack I'll never use at work is fun, but it doesn't help the story.
3. Pick something with one hard problem in it. Multi-tenancy in ShiftTracko. Networking without open ports in the homelab. Tool design in the MCP server. One genuinely hard problem teaches more than ten easy features.
4. Make it small enough to finish, then grow it. Every project above started as something small that worked. Only then did it grow.
What it's taught me so far
Writing forces real understanding. I thought I understood WireGuard, NAT and TLS termination. Then I tried to explain them in plain English, and realised which parts I'd been hand-waving. Writing a post is like a code review of my own knowledge.
Finished beats impressive. A small project that works and is written up is worth more than a big idea that's half done. For the big project, ShiftTracko, I treat it as a series of small finished pieces rather than one giant thing that's "done one day".
Real projects teach things tutorials skip. No tutorial told me that a Wi-Fi repeater would cap my server's speed, or that my BIOS needed a setting to restart after a power cut, or how many small places tenant data can leak if you're not careful. Those lessons only come from running something real.
AI makes a solo developer faster, but not wiser. Cursor and Claude help me move much faster on ShiftTracko and everything else. But the design decisions, the security boundaries and the "is this actually right?" moments are still mine. That's the part I want employers to see.
It changes how I feel about the search. On days when there are no replies, I can still finish something. That matters more than I expected. Job hunting is mostly waiting, and building gives that energy somewhere useful to go, instead of refreshing my inbox.
What building in public isn't
I want to be clear about one thing: this isn't a replacement for applying, networking or improving my CV. I'm still doing all of that.
It's also not a guarantee. A blog won't make a hiring manager call you. It just makes it much easier for them to understand who you are when they do look. It turns "a senior .NET engineer with six years' experience" into a person with real work they can read, try and ask about.
What I'd tell anyone in the same spot
If you're a developer and the applications aren't landing, I'm not going to pretend a blog will magically fix that. The market is what it is, and it's tough right now for a lot of people.
But you can make yourself easier to understand. Pick one thing you'd genuinely like to build, build it properly, and write down what you learned. Then do it again. After a few weeks, you have something that a CV can never be: evidence.
And you'll be a better engineer at the end of it, whatever happens with the search.
What's next
I'm going to keep going. More on ShiftTracko as it grows, more on .NET and AI agents, and more on running real apps on my own infrastructure. And when I do land a role, I'll write the follow-up and share what actually made the difference.
If you're a hiring manager or recruiter and something here caught your eye, I'd genuinely love to hear from you. I'm looking for .NET and AI engineering roles in Australia. You can find me on LinkedIn.
And if you're job hunting too: how are you handling it? Are you building anything on the side? Tell me in the comments.
Comments (0)
🔑 Log in to comment Sign in with your email to like, save and join the discussion.
No comments yet. Be the first!