The Numbers
18 hours, logged, not estimated. Not “a weekend” in the breezy way I framed it in Part 1 — 18 real hours across the build itself and every fix since.
The cost: around $30/month for my Claude subscription, using roughly 1% of my weekly session capacity to make one hire and run the ongoing checks. Notion and Google Drive were already part of how we run Larkwin — no new software, no procurement cycle, no vendor demo calls, no six-week implementation timeline.
I’m not going to dress that up with a formal cost comparison against a traditional HRIS platform — I didn’t run one. But I know from experience that aside from the dollar amount of an out-of-the-box HRIS, the set up alone takes significantly more than 18 hours. So, 18 hours and $30 a month, for a system shaped around how we actually work rather than how a vendor assumed we’d work, is not a hard number to beat.
What Actually Broke
Part 1 and Part 2 were both fairly confident. I was excited and a little bit proud. This is the part where that confidence gets tested, because a lessons-learned post that skips the actual lessons isn’t living our values.
The tax forms. A scheduled daily check is supposed to detect when a new hire’s completed tax forms land in their folder and tick the corresponding box. It missed one. Our first hire had filled out and saved his completed forms the evening before — well ahead of the next morning’s check — but the check still reported them as not received. I only knew it was wrong because he’d texted me directly to say it was done. The root cause, once I dug in: blank template versions of the same forms were sitting in the same folder, and that made “is there now a completed form here” genuinely ambiguous to the system. I hadn’t thought about that when I set the folder up. Fixed it two ways — the check now looks specifically for a _FILLED suffix on the filename, and I pulled the blank templates out of the folder entirely. Small thing. But it’s a real example of the system being wrong and a human catching it, not the other way around.
The stale search result. Later, running a dry-run with a dummy hire to stress-test the whole workflow, a different check told me a signed contract wasn’t in Drive. It was — it had been signed and countersigned days earlier. I pushed back with the exact filename instead of accepting “not found,” and once it opened the file directly instead of trusting the search snippet, it found the signature immediately. What happened: the file had been overwritten in place — unsigned draft replaced by the signed version — but Drive’s search index was still serving text from the old version. A discrete, well-timed event (like an email notification from gmail) turned out to be a more reliable signal than a search index that can lag behind a file that’s changed underneath it. I’ve since started leaning on that instead.
Permissions. Notion’s sharing model turned out to be genuinely unintuitive, and I found that out by getting it wrong on a page with internal-only content on it — a page structure that let access cascade further than I’d intended. I know exactly what the fix is; it just hasn’t happened yet — it’s scheduled for next week, once I have the time to do it properly rather than patch it in a rush.
This is where having an actual AI & Software Engineer join our team – hi Danysh 😊 turned out to be a gift I didn’t fully appreciate until it happened. He came in and, in the course of doing his own job, stress-tested the system in exactly the way I couldn’t from the inside — he knows what good permissions architecture looks like, and I don’t, not yet. That’s not a small thing. A system built by one non-technical founder, tested only by that same founder, has a ceiling. A system that gets used and questioned by someone with real engineering judgment finds its actual edges a lot faster than I would have on my own.
None of this is the technology failing me. It’s the honest cost of building something in domains — permissions architecture, search index behavior, detection logic — where I don’t have deep prior experience. That’s what “built in a weekend, in development” actually looks like, underneath the tidy version I wrote in Part 1.
Here’s the part I think is actually useful to say plainly: at three employees, all of this is fine. A missed checkbox caught by a text message costs nothing. A stale search result caught during a deliberate dry-run costs nothing. A permissions gap found before it caused any real exposure, with a known fix scheduled, is exactly what a stress-test is supposed to produce. None of this would be fine at thirty employees, run by someone who didn’t build the system and doesn’t have the context I do sitting behind every decision. That gap — between “works because I’m watching closely, with good people around me” and “works because it’s actually robust” — is the honest state of this project right now.
Maintenance
What’s happened beyond the initial hire? Onboarding was the smoothest part. Claude and Notion handled the creation of workflows that linked to documents within our secure drive. Before our first 1:1 Claude let me know that Danysh had completed his mandatory training and onboarding tasks. This was a trigger for me in preparation for our 1:1: did I need to follow up on outstanding items or could I move to first week feedback and support? It also ensured we were compliant. From here maintenance hasn’t been needed. I’m iterating and refining the current process, as well as frame-working the LMS and Talent Development modules.
Two Conclusions, Held With Different Confidence
The one thing I can say flatly: this was worth it. I have a HRIS that’s actually shaped around Larkwin: our values, our rhythms, not a vendor’s idea of a generic company. I learned things about system design, automation, and where my own knowledge gaps actually are and I’m already using these on other projects. The learning didn’t stay contained to HR, which is arguably the bigger return. And our first hire’s real, unprompted feedback on the actual experience of being hired and onboarded through this has been genuinely positive. At this stage, for this company, at this scale, I’d make the same call again without hesitation.
The one I’m not going to overclaim: would I never go back to a traditional HRIS? While I’d like to believe that I wouldn’t, I can’t actually say it yet. Everything I’ve built has been tested by me, on a system I built, for our first hire, with full context on every decision behind it — including the two failures above, both of which I caught because I happened to be the kind of person who double-checks a filename or asks why a box didn’t tick. The real test is what this looks like at ten employees, run day-to-day by someone who didn’t build it and doesn’t have that context. I don’t have that data. Anyone telling you they’ve replaced a real HRIS after one hire and three months hasn’t actually tested the claim they’re making — and I’d rather say that plainly than let the first two posts in this series imply more than I actually know.
What’s Actually Next
I’m not closing this series with “mission accomplished.” I’m closing it with: promising, cheap, genuinely ours — and still early, in ways that matter. The next real test isn’t a Part 4. It’s hire five, hire six, hire ten, and whether this holds up when it isn’t just me holding it together by hand.
If you’re thinking about building something similar: start smaller than you think you need to, expect to find real gaps you didn’t know existed, and don’t let anyone — including me, three posts ago — tell you it’s cleaner than it actually is.
Final Thought
It will be super interesting for me to come back to this post in 6 months and see how this article and the series holds up.