# Why I Built JobKick: 25 Years of Building Systems 25 years building systems in a hospital, then FileMaker to React to coding agents. Why I think work tools should do more than just get the job done. By Steven Cappiello, Founder of JobKick · Published 2026-10-10 · Updated 2026-10-15 Canonical: https://jobkick.com/blog/why-i-built-jobkick/ Topics: systems thinking, workplace systems, coding agents, FileMaker to React, in-house developer, building software for teams, JobKick For 25 years, I've built systems for a living. Most of that time I was the in-house developer at a hospital. My users weren't customers in some faraway market. They were down the hall, and every day I got to see whether the thing I'd made helped them or got in their way. For most of those years, my main tool was FileMaker Pro. Then, about two years ago, I started over. Twenty-plus years in, I went back to being a beginner. If you've ever lost an afternoon to software that was supposed to save you time, this one's for you. It's the short version of why JobKick exists, but it isn't really about a product. It's about what happens when you spend a career watching how systems shape the people inside them, and then the tools for building them suddenly change. ![A sepia photograph of a hospital library in the late 1800s: men at long desks, surrounded by tall bookcases full of ledgers.](/blog/why-i-built-jobkick/bellevue-hospital-library.webp) *Hospital systems before software: a library at Bellevue Hospital, New York City, photographed around 1885–1898. The bookcases may hold patient ledgers. From the [Wellcome Collection](https://wellcomecollection.org/works/kyvpdqt5), public domain.* ## Starting over, the slow way I learned React and the other modern tools the way most of us learn anything: badly at first, then a little less badly. I copied and pasted code. I made tiny, careful edits, one line at a time, to see what broke. Slowly I started to understand how an application is actually put together, and not just how to make one screen work. Then I started working with coding agents (AI tools that can read a codebase, write code and run it). The more I learned what they're great at and where they fall short, the smarter my workflows got: the agents take what they do well, and I keep the parts that need judgment. Not instead of understanding the code. On top of it. The results have multiplied. I'd say I'm ten times more productive. That doesn't mean I work a tenth of the hours. It means I do a lot more, and I take on far more ambitious projects than I would ever have tried before. I wasn't alone. Here's how many developers in Stack Overflow's yearly survey said they use AI tools or plan to: **Chart (line): Developers using or planning to use AI tools** — Share of Stack Overflow Developer Survey respondents who answered the AI question, 2023 to 2025. ```json {"unit":"%","x":["2023","2024","2025"],"series":[{"name":"Using or planning to use AI tools","values":[70,76,84]}]} ``` Source: Stack Overflow Developer Survey 2024 (https://survey.stackoverflow.co/2024/ai) (60,907 responses to this question; gives the 2023 figure) · 2025 (https://survey.stackoverflow.co/2025/ai) (33,662 responses). Using the tools and trusting them are different things, though. In the same 2025 survey, more developers said they distrust the accuracy of AI output (46%) than trust it (33%). Only 3% said they "highly trust" it. The agent can be fast. You still have to know what good looks like. ## What two years of this made possible I've gotten very good at it. In the last two years I've built a lot of systems that are helping teams: at companies, in my restaurant, and a music app of my own. One I'm proud of is a credential management system for a research organization: about 1,500 people across 200 labs. Under the hood is a rules engine. It looks at each person's role in their lab and works out which credentials that role requires. Then, every morning, it reminds people before anything lapses. The lab administrators don't have to chase anyone down one by one. Nobody has to remember to follow up. The system does it. JobKick is built the same way it was. It's a working partnership between an experienced human and AI coding agents, and it works because each side does what it's best at. The agents move fast. I decide what's worth building, test it mindfully and carefully, and treat people's feedback as something to handle with care, not a ticket to close. Careful where it counts, fast everywhere else. SyncUp, Timely and Sherli are what came out of that partnership: systems built for teams, by someone who has spent a career building systems for teams. ## Where the name came from Honest version: JobKick started as a name I thought was cool. I bought it a long time ago, around the dot-com bubble, when buying domain names seemed like a good idea. I bought a few that way, each one an idea I found interesting and meant to do something with. It took me a long time to get around to this one. But the name turned out to fit. My whole career has really been about one thing: giving the workplace a little kick in the butt, so the work gets done better and with less wasted effort. ## Most problems live in the system There's an old idea in quality management that I keep coming back to. W. Edwards Deming, the statistician who helped rebuild Japanese manufacturing after the war, wrote in *Out of the Crisis* (1986) that in his experience "94% belong to the system (responsibility of management) 6% special." His point: when work goes wrong, it's usually the system, not the person. That 94% is his estimate from experience, not a measured number. But anyone who has worked in a hospital has seen the idea play out. One study tracked 142 family doctors in Wisconsin through the EHR (the electronic health record, the system that holds patient charts): - **5.9 hrs** of an 11.4-hour workday spent in the EHR, per weekday (source: Arndt et al., Annals of Family Medicine 2017 · 142 physicians, https://www.annfammed.org/content/15/5/419) - **44%** of that EHR time went to clerical and administrative tasks (source: Arndt et al. 2017, https://www.annfammed.org/content/15/5/419) - **1.4 hrs** of EHR work after clinic hours, per weekday (source: Arndt et al. 2017, https://www.annfammed.org/content/15/5/419) Nobody in that study was lazy or bad at their job. The system asked for those hours. That's the part of systems building that gets missed: a system doesn't just record the work. It decides how the work feels. And how work feels isn't a small thing. Gallup's 2025 survey of 141,444 employed people found global employee engagement fell to 20%, its lowest since 2020. Gallup estimates low engagement costs the world economy about $10 trillion a year. Tools aren't the only reason people check out, and I won't pretend they are. But tools that fight you every day don't help. ## Getting the job done is the floor Most workplace software is built to one standard: does it get the job done? The form saves. The report runs. The schedule exists somewhere. That's the floor, not the goal. The systems I want to build think bigger than the task in front of them. They do the job better than the people asking for it imagined it could be done. And they're a pleasure to use, so people actually want to open them, and not just because they have to. Coding agents are what make that standard realistic for a small team, or for one person. When building gets cheaper, "good enough" stops being the only thing you can afford. ## Why this matters if you're not me **If you just want to do your job,** the tools you use decide how your day feels. Those doctors didn't choose to spend 1.4 hours a night catching up on clicks. You're allowed to expect more from your software than "it technically works," and the gap between what's possible and what you're handed is getting wider. **If you run a business or a team,** the math on custom tools has changed. In my experience, a system shaped around how your people actually work, like one that does a lab administrator's follow-up for them, no longer needs a big team and a long project. One experienced builder working with agents can get there. The expensive choice now is putting up with software that makes your people chase each other. **If you work in tech,** the valuable skill is shifting. Typing code matters less. Knowing how a system should be structured, testing it carefully, and listening to the people who use it matter more. The agent gives you speed. Judgment is still yours, and that's the part worth getting good at. ## The fair counterpoint The case against all of this is real, and you should hear it. AI doesn't automatically make builders faster. In 2025, METR (a nonprofit that studies AI) ran a randomized trial with 16 experienced open-source developers on 246 real tasks. With AI tools allowed, they took **19% longer**, and afterward they still believed AI had sped them up by 20%. METR has since said those early-2025 results no longer reflect current tools. Its 2026 follow-up (57 developers, 800+ tasks) says developers are "likely" sped up now, but calls its own data "only very weak evidence" for how much. Part of the reason: many developers declined to take part because they didn't want to work without AI anymore. So no, the agent isn't magic. Feeling fast and being fast are different things. Where I land: AI raises the ceiling on what one builder can make, as long as you understand what you're building. ## If you build systems for people 1. **Sit with the people who'll use it.** Watch the work before you design anything. 2. **Blame the system before the person.** When something keeps going wrong, assume the process is asking for it, and fix that first. 3. **Learn the structure, then bring in the agent.** Copy, paste and edit by hand until you know how the pieces fit. Then let an agent go faster than you could alone. 4. **Check the agent's work like a new hire's.** Most developers don't fully trust AI output. They're right not to. 5. **Count the hidden hours.** Clerical clicks, after-hours catch-up and re-entering the same data are where a system quietly costs people the most. 6. **Aim past "it works."** Ask what the job would look like if the tool were great, and build toward that. There's a lot more to say about specific systems and what each one taught me, and I'd like to write those up too. If you build things for the people you work with, in a hospital, a restaurant, an office or anywhere else, what's the system you wish someone would finally fix? Tell me in the comments. ## Sources - Stack Overflow (2025), [2025 Developer Survey: AI](https://survey.stackoverflow.co/2025/ai). 33,662 responses on AI tool use; 33,244 on trust. - Stack Overflow (2024), [2024 Developer Survey: AI](https://survey.stackoverflow.co/2024/ai). 60,907 responses; reports the 2023 figure (70%). - Deming, W. E. (1986), *Out of the Crisis*, p. 315, quoted in [Digestible Deming, "Who's to Blame?"](https://digestibledeming.substack.com/p/whos-to-blame). - Arndt, B. G. et al. (2017), [Tethered to the EHR: Primary Care Physician Workload Assessment Using EHR Event Log Data and Time-Motion Observations](https://www.annfammed.org/content/15/5/419). *Annals of Family Medicine* 15(5):419–426. 142 family medicine physicians, July 2013 to June 2016. - Gallup, [State of the Global Workplace](https://www.gallup.com/workplace/349484/state-of-the-global-workplace.aspx). 2025 data: 263,810 respondents, 141,444 employed. - METR (July 2025), [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/). 16 developers, 246 tasks, randomized. - METR (February 2026), [We are Changing our Developer Productivity Experiment Design](https://metr.org/blog/2026-02-24-uplift-update/). 57 developers, 143 repos, 800+ tasks.