Part 7: Building for the Next User

The first version of RoleFinder had my resume hardcoded directly inside an n8n node. Sixty-plus lines of text, pasted right into the workflow JSON. Every time the AI evaluated a job, it pulled my experience, my target criteria, my preferences from that embedded block. It worked. But it was ugly, and I knew it.

I told myself I’d clean it up later. Ship first, refactor second. The system was sending daily emails. Mission accomplished.

Except I couldn’t stop thinking about it.

Partly because hardcoded personal data is a security no-no. Partly because I wanted to open-source this eventually, and nobody wants to scrub their resume out of every commit.

But mostly because I could already see this wasn’t just for me.

People in my job-hunting communities had started asking about it. Could they use it? Could I run it for them? What would it take to support someone else’s profile?

With the resume hardcoded, the answer would be: copy the whole workflow, find the node, paste in their data, hope you didn’t break anything. That’s not a system. That’s a hack.

So I refactored. Moved the profile into a database table. One query at the start of the workflow, passed through as context to every sub-workflow that needs it. Now switching profiles is a database row, not a code change. Adding a new user doesn’t touch the workflow at all.

It took a few hours. It was the first thing I did after end-to-end worked.

Here’s the lesson I keep relearning: think about the next user before you’re done being the first. Not because you’re building a product. Because the next user might be future you, trying to remember why you made the choices you made.

Next up: the debugging nightmare that almost broke me.

Categories:

Leave a Reply

Your email address will not be published. Required fields are marked *