Forem: Harry Wynn

Why I Built My Own MySQL Client for macOS (SQL Gnome)

Harry Wynn — Mon, 13 Apr 2026 16:02:25 +0000

I’ve been building software professionally for more than 25 years, and like most developers, I spend a lot of time inside databases. MySQL in particular shows up everywhere: analytics systems, internal tools, production apps, and quick debugging sessions.

Over the years I’ve used a lot of database clients. Some were good. Some were frustrating. Eventually I reached a point where I kept thinking:

“Why does this feel harder than it should?”

That question is what led me to build SQL Gnome, a native MySQL client for macOS focused on speed and simplicity.

The Problem With Existing Tools

Most database clients fall into one of a few categories.

Electron apps

A lot of modern tools are built with Electron. That’s not inherently bad, but it often means:

high memory usage
slow startup
UI lag when browsing large tables

When you're opening a database client dozens of times a day, those little delays add up.

Feature overload

Some clients try to do everything:

schema design
migrations
visual query builders
dashboards
collaboration layers
cloud integrations

For some teams that’s great.

But most of the time I just want to:

run queries
browse tables
inspect results
move on

The extra complexity ends up getting in the way.

Subscription fatigue

Another trend is database clients moving to subscription pricing.

For teams that makes sense. But for individual developers, it can feel strange paying monthly just to run SQL queries.

What I Wanted Instead

When I started thinking about building my own client, I kept coming back to a few simple goals.

I wanted something that was:

Fast

launches instantly
runs queries without lag

Simple

clean interface
minimal setup

Native

built specifically for macOS
not a cross-platform wrapper

Focused

query execution
table browsing
result inspection

No dashboards.

No workflow engines.

No unnecessary complexity.

Just a solid tool for working with MySQL.

How SQL Gnome Works

The goal with SQL Gnome is to make working with MySQL quick and straightforward.

Connect to a database

Add your connection details and connect instantly.

Run queries quickly

Write your SQL and execute it immediately.

The editor is intentionally minimal and focused on speed.

Browse tables

You can quickly explore schemas and inspect table contents without needing to write queries for everything.

Explore table structure

Understanding a database quickly often starts with understanding its schema.

SQL Gnome lets you inspect table structure instantly — columns, data types, keys, and indexes — without writing DESCRIBE or SHOW CREATE TABLE queries.

This makes it easy to understand unfamiliar databases or debug schema issues.

Why the Name "SQL Gnome"?

Honestly?

I like tools with personality.

Not every development tool has to look like a corporate dashboard.

The idea was a small, helpful tool that quietly does its job while you focus on your work.

Lessons Learned While Building It

Building a developer tool teaches you a lot about what developers actually care about.

Speed matters more than features

Developers forgive missing features.

They don't forgive slow tools.

Simplicity is surprisingly hard

Adding features is easy.

Deciding what not to build takes much more discipline.

Small details matter

Things like:

keyboard shortcuts
query formatting
scrolling behavior
rendering large result sets

Developers notice these details immediately.

Try SQL Gnome

SQL Gnome is still early, and I’m continuing to improve it based on feedback.

If you spend a lot of time working in MySQL, I’d love to hear what would make a tool like this better.

Download SQL Gnome

👉 https://sqlgnome.com

Feedback and suggestions are very welcome.

Why Most Applicant Tracking Systems Are Overkill for Small Teams (So I Built My Own)

Harry Wynn — Sun, 08 Mar 2026 20:06:56 +0000

After 25 years building software and working with recruiting systems, I've developed a strong opinion about ATS platforms:

Most of them are wildly overbuilt for what small teams actually need.

Startups and small agencies usually just want to:

track candidates
move them through a pipeline
search resumes
leave notes

Instead they get massive enterprise systems full of CRM layers, automation engines, and reporting dashboards nobody uses.

So I decided to build something different:

An open source ATS designed specifically for small teams.

I call it Hire Gnome.

The Problem: Modern ATS Platforms Are Built for Enterprises

If you've worked with systems like Bullhorn, Greenhouse, Lever, or Workday, you know the pattern.

They are designed around:

large recruiting teams
complex workflows
heavy integrations
enterprise reporting requirements
expensive licensing models

All of that complexity trickles down to smaller organizations that don't actually need it.

Typical small-team requirements are much simpler:

Track candidates
Store resumes
Move people through a hiring pipeline
Add notes
Search candidates
Maybe collaborate with one or two other people

That's it.

But instead they end up paying for systems that include:

complex permission models
giant CRM layers
sales pipelines
automation engines
enterprise compliance tooling
reporting dashboards nobody actually uses

The result is tools that are expensive, slow, and hard to customize.

The Idea: A Simple ATS That Developers Can Actually Run

The core idea behind Hire Gnome is simple:

An ATS that developers can run themselves.

Instead of SaaS lock-in, the project is designed around:

self-hosting
open source transparency
simple architecture
easy customization

The mental model is closer to tools like:

Plausible analytics
Metabase
Ghost
Outline

Install it, run it, own your data.

Small teams get a lightweight ATS.

Developers get something they can extend.

Core Design Principles

Before writing code, I wrote down a few rules the project had to follow.

These guardrails have helped keep the scope from exploding.

1. Simple First

If a feature doesn't help a small team hire someone faster, it probably doesn't belong.

That eliminates a surprising amount of ATS complexity.

No giant CRM layer.

No unnecessary automation engine.

No 50-step workflow configuration.

Just a pipeline and candidates moving through it.

2. Search Matters More Than Everything Else

One of the biggest frustrations with ATS systems is bad search.

Recruiters often rely on keyword matching that fails constantly.

Example:

"Frontend engineer with modern JavaScript frameworks"

But the resume says:

"React developer"

Traditional ATS search misses this.

Hire Gnome is being built with semantic search as a first-class feature, not an afterthought.

This is an area where modern AI tooling actually makes a meaningful difference.

3. Developers Should Be Able to Extend It

Most ATS systems are black boxes.

If you want to integrate something custom — good luck.

Hire Gnome is intentionally built so developers can easily:

add integrations
modify workflows
extend the data model
build custom reporting

That means keeping the architecture straightforward.

The Architecture (So Far)

The current stack is intentionally boring.

That's a good thing.

Backend

A Node.js service responsible for:

candidate CRUD
pipeline management
search indexing
API access

A clean REST API makes integrations easier down the road.

Database

A relational database holds the core entities:

Candidates
Resumes
Pipeline stages
Notes
Activities

This keeps reporting straightforward and avoids unnecessary complexity.

Resume Storage

Resumes are stored as structured text rather than relying purely on raw document formats.

This enables better indexing and search.

A simple transformation pipeline converts uploads into normalized text.

Search Layer

Search is where things get interesting.

Instead of traditional keyword-only search, Hire Gnome uses a hybrid approach:

Keyword + semantic matching

The goal is to allow queries like:

"Find backend engineers with API experience"

and return candidates who mention things like:

Node
REST
GraphQL
microservices

even if the exact words don't match.

This dramatically improves candidate discovery.

What I'm Trying to Avoid

One of the easiest ways to ruin software is letting it slowly accumulate features.

ATS systems are especially prone to this.

Some examples of things I'm deliberately not building (at least not yet):

Sales CRM

Many ATS products try to combine:

recruiting
sales pipelines
account management

Those are different problems.

Hire Gnome focuses on hiring pipelines only.

Over-Engineered Workflow Systems

Some ATS platforms allow you to build extremely complex hiring workflows.

In practice, most teams use something like:

Applied Screen Interview Offer Hired

That's enough.

Flexibility without excessive configuration.

Giant Analytics Dashboards

Analytics are useful, but most teams only care about a few metrics:

time to hire
pipeline health
candidate volume

Those can be added later without building a massive reporting subsystem.

The Open Source Model

Hire Gnome is being built as open source first.

The idea is similar to the model used by many developer tools:

The core platform is free and self-hosted.

Revenue (eventually) comes from things like:

managed hosting
setup and deployment
custom integrations
support

Small teams that can run it themselves pay nothing.

Teams that want help can pay for services.

Why the Name "Hire Gnome"

Because every hiring team deserves a small helper behind the scenes doing the hard work.

Also, most good startup names were taken sometime around 2008.

What Comes Next

Right now the focus is on building the core pieces:

candidate ingestion
pipeline management
resume indexing
semantic search
simple UI for recruiters

Once those pieces are stable, the roadmap likely includes:

email ingestion
calendar integration
resume parsing improvements
API integrations

But the priority is keeping the system simple and reliable first.

Lessons So Far

Even early in development, a few lessons have already been clear.

1. Simplicity is harder than complexity

It's surprisingly easy to add features.

It's much harder to say no to them.

2. Search is the real value

Tracking candidates is easy.

Finding the right candidate later is the hard part.

3. Open source forces better design

When people can see your code, you naturally build cleaner systems.

The Bottom Line

Recruiting software doesn't have to be bloated enterprise tooling.

For small teams, hiring should be simple:

Collect candidates → evaluate them → hire someone great.

Hire Gnome is an attempt to build an ATS that reflects that philosophy.

Small.

Transparent.

Developer-friendly.

And hopefully useful.

If you're interested in the project or want to follow along as it develops, I'd love to hear feedback from other developers or recruiters who have suffered through the current generation of ATS tools.

Building a Production RAG System for Resume Search: What Actually Worked (and What Didn't)

Harry Wynn — Thu, 13 Nov 2025 00:07:31 +0000

After 25 years in software development, I recently tackled a problem that's becoming increasingly common: implementing a production-ready RAG (Retrieval-Augmented Generation) system using AWS Bedrock Knowledge Bases. The use case was resume search for a recruiting database, and the results were significant enough that I wanted to share what worked, what didn't, and the gotchas I hit along the way.

The Problem: Keyword Search Isn't Enough

Recruiters were drowning in manual work. They'd run keyword searches against the resume database, then spend hours manually sifting through results trying to match candidates to job descriptions. The core issue? Basic keyword search doesn't understand context or semantic meaning.

A job description asking for "frontend expertise with modern JavaScript frameworks" might miss excellent candidates whose resumes say "React developer" or "Vue.js specialist" because the exact keywords don't match. Recruiters were compensating by running dozens of search variations, then manually evaluating each result.

The pain point: Searches that should take an hour were taking 2 days or more to compile a quality candidate list.

The Solution: AWS Bedrock Knowledge Base with Semantic Search

Instead of making recruiters search harder, I inverted the problem. The system takes a job description, generates an optimized semantic query, and searches the knowledge base for candidates whose experience actually matches what the role needs - not just the keywords used to describe it.

The architecture is straightforward:

Data source: Bullhorn ATS
Data transformation: Resumes exported and converted to Markdown files with recruiter notes embedded for additional context
Storage: Transformed files in S3
Vector store: AWS Bedrock Knowledge Base with OpenSearch Serverless
Embeddings: Cohere Embed model
Query processing: Job descriptions converted to optimized prompts before querying

The Markdown transformation was critical - it provided a clean, consistent format while preserving the recruiter context that often makes the difference between "technically qualified" and "actually a good fit."

The Chunking Strategy That Actually Worked

This was the most critical decision and took the most trial and error.

What I Tried First (That Didn't Work Well)

My initial approach used semantic splitting - breaking documents at natural boundaries based on content meaning. The theory was sound: keep related information together. The results were... okay. Not terrible, but not targeted enough. Search results felt scattered, like the system was giving me pieces of information from across someone's entire career instead of the relevant parts.

What Actually Worked: Fixed-Size Chunks with Overlap

I switched to 400-character chunks with 20% overlap (80 characters of overlap between adjacent chunks).

Why this worked better:

Consistency matters for vector search. Fixed-size chunks create more uniform embeddings, which means more predictable search results. When chunks vary wildly in size (which happens with semantic splitting on resumes), you get inconsistent matching quality.

Overlap prevents context loss. A candidate's key qualification might span a chunk boundary. The 20% overlap ensures that critical context doesn't get split awkwardly. If someone's resume says "Led migration from Angular to React, reducing bundle size by 40%," you want that whole thought captured somewhere.

Shorter chunks = more precise matching. At 400 characters, each chunk represents a focused piece of someone's experience. When a query matches, you're getting specific relevant context, not an entire job history.

The difference was noticeable immediately. Search results became more focused and relevant sections of resumes consistently bubbled to the top.

Metadata: What Mattered and What Didn't

This is where the real power comes in. Raw semantic search is good; semantic search + metadata filtering is game-changing.

Metadata I Attached to Each Chunk:

Title (job title)
Department
Recruiter (who sourced them)
Skills (extracted skill list)
Companies (employment history)
Education
Location
Email

What Actually Got Used:

Department filtering was huge. Being able to search within "Accounting" vs "Creative" vs "HR" immediately cuts noise and improves relevance. When you're filling a finance role, you don't want creative professionals showing up just because they mentioned "budgets" in their portfolio management section.

Skills metadata let recruiters combine semantic search with hard requirements. "Find candidates whose experience matches this job description AND have Python + AWS in their skills list" catches people who might describe their work differently but have the required technical background.

Location filtering became essential for roles that weren't fully remote. No point showing Dallas candidates for a NYC office-required position.

The other metadata fields were valuable for the application layer but didn't significantly improve search quality itself. They're worth capturing, but they're not doing heavy lifting in the retrieval step.

Real Results: 2 Days or More to 2 Hours

The numbers tell the story:

Before: Compiling a quality candidate list for a specialized role took 2 days or more of recruiter time - running multiple keyword searches, manually reviewing resumes, cross-referencing requirements.

After: Same task took 2 hours. The recruiter reviews the job description, the system returns ranked candidates with relevant experience highlighted, and they spend their time on actual evaluation instead of archaeological searches.

Quality validation: When we tracked placements, candidates that were actually hired appeared in the top search results the majority of the time. The system wasn't just faster - it was finding the right people.

The Biggest Gotcha: Indexing Strategy

This cost me the most time. My initial implementation used inline documents (sending resume content directly to Bedrock via API). It worked, but indexing was painfully slow - we're talking days to process and index resumes from Bullhorn.

One important note: resumes are only indexed if they have been updated witin the past 2 years. Anything older than that quickly loses relevance in the recruiting world - skills change, candidates move on, contact information goes stale. This scoping decision kept the database manageable and ensured search results stayed current.

The fix: A two-step transformation process. First, I exported resumes from Bullhorn (filtering for the past 2 years) and converted them to Markdown files, embedding recruiter notes as additional context within the documents. Then I stored these transformed files in S3 and pointed the Knowledge Base at the bucket.

Result: Indexing time dropped from days to hours.

Why did this work so much better?

AWS Bedrock Knowledge Bases are optimized for S3-based workflows. The service can parallelize file processing much more efficiently than handling inline content through API calls.

Markdown provided structure and consistency. Instead of dealing with varied resume formats (PDFs, Word docs, text files), everything became clean, parseable Markdown. This consistency improved both indexing speed and search quality.

Recruiter notes added critical context. When a recruiter writes "Strong cultural fit for startup environments" or "Excellent communicator, handled difficult client situations well," that context gets indexed alongside technical qualifications. The semantic search can now match on soft skills and work style, not just keywords.

If I were starting over, I'd go straight to the Markdown transformation approach and save myself a week of frustration. Plus, updates became simpler - export from Bullhorn, transform to Markdown, drop in S3, trigger a sync, done.

What I'd Still Improve

This system is production-ready, but it's not perfect. It's a work in progress, and there are areas I'd continue refining:

Dynamic chunk sizing based on content type. Resumes aren't uniform - executive resumes vs junior developer resumes have different information density. Adaptive chunking might improve results further.

Better handling of acronyms and industry jargon. The system sometimes misses matches when candidates use acronyms (e.g., "K8s") vs full terms (e.g., "Kubernetes"). Some preprocessing or synonym expansion could help.

Query optimization based on role type. Different job categories (engineering vs sales vs finance) might benefit from different query formulations. There's room to tune the prompt generation based on department.

Lessons Learned

Start with fixed-size chunking. It's simpler, more predictable, and easier to tune than semantic splitting. You can always get fancier later.
Overlap is worth it. The 20% overlap prevented edge cases where important context got split. The storage cost is negligible compared to the quality improvement.
Metadata filtering is not optional. Semantic search alone is good. Semantic search + metadata filtering is what makes the system production-ready.
Transform your data into a consistent format. Converting everything to Markdown before indexing improved both speed and quality. If you're working with an ATS or any heterogeneous data source, the transformation step is worth the effort.
Use S3 for document storage from day one. Don't make my mistake of starting with inline documents.
Embed human context wherever possible. Recruiter notes added dimensions that pure resume text couldn't capture. If you have expert annotations, comments, or contextual notes in your source system, include them.
Measure what matters. We tracked time-to-candidate-list and placement rates. Those metrics proved the system's value and guided optimization priorities.

The Bottom Line

Implementing RAG systems with AWS Bedrock isn't rocket science, but the details matter. The difference between "okay results" and "recruiters will use this every day" came down to chunking strategy, metadata design, data transformation, and infrastructure choices.

For this use case, the combination of pulling from Bullhorn ATS, transforming to Markdown with recruiter context, using 400-character fixed chunks with 20% overlap, rich metadata filtering, and S3-based storage created a system that genuinely improved recruiter productivity. Searches that took 2 days or more became 2-hour searches, and the candidates being placed were consistently appearing in top results.

If you're building similar systems - whether for recruiting, document search, customer support, or any other knowledge retrieval application - the principles transfer. Start simple, measure results, and optimize based on what your users actually need. And if you're working with data from an ATS, CRM, or any structured system, invest the time in a clean transformation pipeline. It pays dividends.

Need help implementing AWS Bedrock Knowledge Bases or optimizing your RAG system? I do consulting and implementation work through Concept Cache. Feel free to reach out if you're hitting similar challenges.

Update: Turning This Into a Real Product

Since publishing this article, I’ve started turning some of these ideas into a real project.

I'm building an open source ATS for small teams called Hire Gnome.

The goal is simple:

lightweight candidate tracking
strong resume search
semantic search built in from the start
something developers can self-host and customize

A lot of the lessons from this RAG system are shaping how search works inside the platform.

If you're interested, you can read about the project here:

👉 Why I Started Building Hire Gnome

I'd also love feedback from anyone who has wrestled with ATS systems before.