Welcome back to "Shelved Projects", a series where I open up the archives to share systems that were technically functional and highly optimized, but ended up shelved.
Today’s project is personal. It’s called Talent by UnitBuilds (TUB)—a high-concurrency, Go-native sourcing and compliance engine. It wasn't built as a vanity project or to chase a tech trend. It was built to solve a systemic barrier: the invisible wall that bins your resume simply because of the country listed in your address.
The Root Problem: The "Not from the USA" Bin
You can send 1,500+ CVs. You can build bespoke demo apps for target roles to prove your worth. Yet, you won't get a single shortlist. Why? Because the moment a Western HR department reads "Namibia" (or India, or Brazil, or Romania), they see administrative risk, compliance overhead, and tax complications. So, they bin the resume.
Meanwhile, I am stuck writing Blazor daily for $1,000 a month, knowing that overseas companies were paying entry-level developers five times that amount for work I could do in my sleep.
The divide is tragic. Opportunities are lost not because of a lack of capability, but because of HR bureaucracy. That is why I built TUB.
How TUB Works: The 1-to-1 Match & Sourcing Swarm
Unlike massive talent platforms that spam employers with hundreds of resumes, TUB operates on a strict 1-Candidate-to-1-Job matching philosophy.
The engine works in five distinct stages:
- The AI Onboarding Interview: The candidate talks to an AI agent (powered by Gemini 3.1 Flash-Lite) to carve out their specific niche. The AI structures their raw resume into a validated JSON schema, focusing on: $$\text{Experience} \rightarrow \text{Education} \rightarrow \text{Skills}$$
- Deep Sourcing Swarms: The platform seeds background crawler tasks (simulated, awaiting full MCP-Lite integration). These crawlers scan LinkedIn and job boards looking for roles that fit the candidate like a glove. It doesn't just match keywords; it reads the target company's core specialty, what the candidate focused their assignments on at university, and the specific architecture of apps they are used to building.
- The Target HR Pitch: The system selects exactly one candidate for one job and fires a highly personalized outreach email to the company's HR department explaining exactly why this candidate fits their exact codebase, along with a 1 page summary of why they shouldn't just bin it.
- Interactive Validation: The link in the email leads HR to a custom client-side profile showing the candidate's verified capability—not just credentials or locality.
- Inverted Sourcing: If an employer posts a job, the system runs the swarm in reverse. It crawls the web for matching candidates (whether they are registered on TUB or not) and reaches out to them with a personalized description of why they were chosen.
The Business Model: Disrupting Recruiter Fees
Normally, recruitment agencies charge companies 15% to 25% of a candidate's annual salary as an upfront placement fee. On a $100k job, that’s $25,000 just to get the developer in the door. In addition, recruiters often collect a $500 kickback from EOR (Employer of Record) providers if the developer is hired internationally.
TUB eliminates the recruiter cut entirely:
- Neither the employer nor the employee pays a penny to the platform upfront.
- Instead, TUB partners with an EOR provider and takes a recurring 10% referral kickback from the EOR's monthly management fee.
To hire a remote candidate legally, an employer needs an EOR to act as the local legal employer, handling local tax withholding and labor laws. Legacy EORs (like Remote) charge around $600 a month per employee and require a steep 3-month security deposit. For an employer testing a new remote candidate, putting down thousands in deposits is a massive friction point.
By partnering with RemoFirst ($200/month, no deposit), the compliance cost would drop to $200/month, and TUB takes a recurring $20/month cut, till we can negotiate bulk discounts, eg. $150 a month, dropping TUB's recurring cut to $15. It's not about making money, it's about creating a platform where people like me don't have to struggle for a job.
The "Self-Funded" Mode
To make the decision a absolute zero-risk "yes" for Western employers, I built a Self-Funded EOR mode:
[Employer Pays: $2,000]
│
▼
[RemoFirst EOR: $200] ─── (10% Kickback) ───> [TUB Platform: $20]
│
▼
[Employee Receives: $1,800]
If a candidate toggles "Self-Funded" mode, the $200 EOR fee is absorbed into their gross asking rate. The employer pays exactly $2,000, RemoFirst takes $200 ($20 goes to TUB), and the candidate receives $1,800.
To someone in a high-cost country, losing $200 seems like a raw deal. But to a developer in a tech deadzone where $1,800/month is a life-changing, high-tier salary, it is an incredible deal. It turns the candidate into a $0 acquisition cost option for the employer.
The Technical Implementation
To keep operations running on a shoestring budget, I engineered the entire backend in Go with two primary optimization focus areas:
1. Zero-Overhead Client-Side EOR Merging (pdf-lib.js)
Instead of parsing, templating, and generating PDFs on the server (which bottlenecks CPU usage and forces temporary storage of sensitive draft agreements), I shifted the contract builder to the client's browser.
The employer uploads their standard agreement, the frontend fetches the template remofirst_addendum.pdf, merges the two locally, and renders it in an iframe. The server only receives the final metadata and signed hash.
// Fetch the EOR Addendum and merge locally in the browser
const addendumRes = await fetch('/static/remofirst_addendum.pdf');
const addendumBytes = await addendumRes.arrayBuffer();
const userPdfBytes = await file.arrayBuffer();
const pdfDoc = await PDFLib.PDFDocument.load(userPdfBytes);
const addendumDoc = await PDFLib.PDFDocument.load(addendumBytes);
const copiedPages = await pdfDoc.copyPages(addendumDoc, addendumDoc.getPageIndices());
copiedPages.forEach((page) => pdfDoc.addPage(page));
const mergedPdfBytes = await pdfDoc.save();
2. High-Concurrency SQLite WAL Tuning
To handle simulated sourcing swarms writing status updates while employers read candidate data, I configured SQLite with Write-Ahead Logging (WAL) and a busy timeout:
dsn := fmt.Sprintf("%s?_journal_mode=WAL&_busy_timeout=5000&_foreign_keys=ON", filepath)
db, err := sql.Open("sqlite3", dsn)
db.SetMaxOpenConns(1) // Mitigate concurrent write locks
Why I Shelved It: The payment divide
If the software works, the monetization is sound, and the need is desperate, why is this project shelved?
Because life gets busy. Between managing my day job, buying a house, moving, taking on a second job, and juggling side-projects, the sheer amount of administrative paperwork required to launch a compliance startup became a wall.
But the real, tragic bottleneck is systemic: Namibia does not support PayPal withdrawals.
To wire in RemoFirst's API and set up recurring referral payouts, I need a global commercial banking pipeline that connects to my local accounts. The key to my salvation is locked behind the very financial and geographic walls I am trying to break down. The project sits on the shelf, fully operational, waiting for the day I have the time and capital to solve the corporate registry logistics.
Lessons Learned
- Build for Zero Friction: Shifting EOR fees to the candidate and automating the contract merge on the client removes every excuse an employer has to say no.
- Architecture is Easy, Logistics are Hard: As developers, we focus on code quality, JIT compilers, and database tuning. But the hardest part of any real-world startup is always banking, legal entities, and regional bureaucracy.
- Keep Shoveling: The code remains ready. The design patterns are validated. The fight for remote talent equity goes on.
Top comments (11)
One small thing on the SQLite setup, since you went to the trouble of turning on WAL. SetMaxOpenConns(1) quietly cancels most of what WAL buys you, because WAL's whole trick is letting readers keep going while a single writer works, and a pool of one forces every read to queue behind every write anyway. The common fix is two pools against the same file, a writer capped at one connection and a separate reader pool that can open many. Keep the busy_timeout as the safety net and your simulated swarm reads stop stalling on status writes. Also, that ending genuinely got me, the tool for escaping the wall being stuck behind the same wall is rough.
That's exactly, why SQLite is just for dev environment, postgresql is for production and there... With the 12 part series, I've noticed that NDA format just work better, so might actually rewrite it to use NDA instead of SQL in general just for the sake of maximum security and performance? The SQLite is just for the dev environment when I built it, because it was still on a mock MCP-Lite, so data derived was still mock data, the main reason I didnt update it to include MCP-Lite, is because since then, i built NMCP and NDA, which could lower overhead and make it far more efficient than I could ever imagine, so worth expanding on when I get the time.
Yip, that's the crux of it all, I cant make money off it, because any money made, cant be paid out. I guess there's a chance that RemoFirst would route the money for me, but relying on a partner to provide payment, without a dedicated payment platform seems to me like a problem waiting to happen...
The gut punch is the ending. The tool that breaks the geographic wall is locked behind the same geographic wall. That’s not a footnote, that’s the whole shape of a deadzone the exit is gated by the thing you’re trying to exit “Architecture is easy, logistics are hard” is the most honest line a builder can write, and almost nobody writes it. We obsess over WAL tuning and ship the elegant part, then a banking rail nobody warned us about decides whether the thing lives or sits on a shelf fully operational. That’s the most frustrating kind of done. For what it’s worth, 1-to-1 matching instead of spraying 200 resumes is the right instinct it respects the employer’s attention, which is the actual scarce resource. Don’t let this one stay shelved, man. The need didn’t go anywhere.
Exactly, the goal was for it to be a trusted resource by reputation. If an employer gets 1 good candidate from it, they'll come back for more, because working through an EOR, means it's not an employee, it's a B2B agreement on paper, the EOR is the actual employer. Which means no stupid laws like "this position must first be vetted against 10 locals, then 10 within the EU, before any foreign candidate may be considered, or we fine you and force you to fire them" which was a nice little fine-script that makes it smarter than hiring locally
That’s the part I didn’t have visibility into the EOR isn’t just a payment pipe, it’s a legal reclassification that routes around the “must vet 10 locals first” rule entirely. So the wall isn’t just HR bias at the resume stage, there’s a second wall baked into labor law that most people never even see because they never get far enough to hit it. The bank rail being the thing still blocking you from collecting your own cut is brutal irony on top of that.
Yip... That's why the second things calm down, I'll contact RemoFirst (my first option) for a partnership + API linkage, so their addendum can be added to the contract and so my point of profit can be connected. $20 a month is far more than I want from the system, but it's a start, that's why as I scale prices down, my cut shrinks, so it earns less money per client and dynamically relies more on bulk than individual pricing. $20 covers roughly 100 candidates per month in cloud compute (resume + searches), which is a good enough factor for me, the idea isnt to make money, it's sustainability and consistency.
@xulingfeng Just FYI, incase they're a scam, I have no affiliation at all with that Sam Tech guy. Had to make that clear, cuz it's a bit odd that he talked about hiring for a US company, when I'm about to make a post on exactly that 🫠 and now I caught you with the click-bait red flag 😁
🤣🤣🤣
Some comments may only be visible to logged-in visitors. Sign in to view all comments.