AI agents can now do a lot of the work I used to do to build DocSpring. That's exciting when I look at my backlog, and slightly less comfortable when I think about someone else using the same tools to build a competing product.
Nico Jeannen wrote about this on X: AI has made basic SaaS products much easier to build and copy. He was responding to Olly's post about founder exhaustion and the worry that AI could make their businesses redundant. I understand both reactions.
DocSpring fills and generates PDFs and Word documents, and collects e-signatures. I founded it as FormAPI, and our team now uses AI agents throughout development and operations. I spend far less time writing code myself. I've also been working harder than ever.
I'm finally working through feature ideas and bugs that sat in the backlog for years. But even with agents doing much of the implementation, running the business takes a lot of attention. Customers keep using what we've already shipped while we decide what to change next. Each change has to fit the product they're relying on.
Building the document platform I had in mind
Agents are saving me so much time that it keeps changing what I think we can build.
One of the main reasons I renamed FormAPI to DocSpring was that I wanted to build a broader document automation platform. Filling PDF forms was the starting point. I wanted people to be able to create and automate other kinds of documents too, but there was always more work to do on the product we already had.
We've now shipped Word templates and the Page Designer. You can upload a Word document with placeholders and fill it with data, or design a document directly in the browser without starting from an existing file. These are two features I wasn't sure I'd ever get around to building. Seeing them in the product makes the name DocSpring feel much closer to what I had in mind when I chose it.
Our release notes show how much else has changed over the last few months. Alongside those new template types, we've redesigned the website and the app, and shipped API v2. E-signing has had a huge amount of work too, including signer roles and emails to send signing links, reminders, and completed documents.
One e-signing problem had been stuck for a particularly long time: figuring out how to seal PDFs with a certificate trusted through the Adobe Approved Trust List. We've finally settled the approach, although we're still waiting for the certificate to be issued. That work involved researching certificate providers and their requirements as well as writing the sealing code. Having an agent help with that research let us make progress on something I had struggled to figure out for years. When I researched this myself a few years ago, it was prohibitively expensive for a small startup, with contracts starting at $50k per year. AI agents helped me research and reach out to every vendor we could find, and we've finally found a vendor who can supply a certificate for only a few thousand dollars per year. We can also bring our own cloud HSM. (Other vendors will only send you a certificate on a USB stick that you have to plug into a physical server.)
We've also reached things further down the backlog. Side-by-side previews now work across every template type, so you can keep the filled document visible while editing. A customer had asked for this years ago, and it kept getting pushed further down our backlog as new, more urgent tickets kept piling up. I simply wasn't able to get around to it when I had to write all the code and fix all the bugs myself. We also rebuilt our Alpaca.js web forms with react-jsonschema-form, which generates React forms from a JSON schema, and added form sections so a long form can be split into steps.
These are projects I would once have had to tackle one after another, and each one would have taken me weeks or months. Now an AI session can work on how a Word document renders while another works on how a long form is split into sections. I move between them when they need a decision, while implementation and review continue in the other sessions.
Keeping all of this moving
This period in time reminds me of the first few months of building FormAPI, when I worked on it non-stop. Work, eat, sleep, repeat. Now a difficult dependency or infrastructure problem doesn't necessarily mean putting all the product work aside. An agent can investigate it and bring me a reproduction or a proposed fix while I work with another session. I currently use Herdr to manage 49 different Claude Code sessions that each focus on a different task or product area. 26 of these sessions are currently "active", and only a dozen or so will be working on things in parallel. I often have a long list of sessions that are waiting for me to read something and make a decision, so I spend my days jumping between sessions, mostly reading updates and answering questions. The rapid context switching was difficult at the beginning, and I would end each day utterly exhausted. But I've been getting used to this workflow, and I don't find it so challenging anymore.
Some of those Claude Code sessions have an ongoing job. I have one that works through big batches of bug fixes, taking a collection of smaller problems through investigation, implementation, and review. Another is devoted to Sentry, the service that reports errors from our application. It investigates the errors, works on fixes, and sorts out which reports are noise that we can ignore. The bug backlog and the errors showing up in the running product both get attention while other agents work on new features.
I have a separate session for performance. Its job is to investigate slow pages and make sure the app feels fast to use. Recent work has involved tracing slow database queries, changing indexes and how we fetch records, and measuring the result after deployment. Another agent works on our CI pipeline (the automated checks that run when we push code). With so many branches being worked on, I care about both how quickly those checks finish and what they cost. We've moved many jobs onto my home servers, while keeping the option to run them in CircleCI's cloud. The agent works on the pipeline itself so the other sessions can keep getting their changes tested.
These jobs used to compete much more directly with feature work for my time. Now I can have agents working on reliability and performance while other sessions build the bigger things I want to launch. I still have to set priorities and review what they propose, but choosing to work on a new feature doesn't mean all of that maintenance has to wait. Product changes still go through automated checks, code review, and staging QA before production. Having more work in progress makes that process more important, and agents do much of the work of running checks, reviewing changes, and fixing what they find.
Our Sorbet work would have been hard for me to justify before I started working with AI agents. Sorbet is a type checker for Ruby. Agents helped us type the application, and then we built our own plugins so it could understand more of our Rails code and templates. Maintaining a customized type checker is the sort of project I once assumed was out of reach alongside everything else we needed to do.
Finishing these projects still involves our team reviewing the result and getting it released. We've built Rack Gateway so agents can prepare server commands and deployments and bring me the actual code or commit to approve. That saves me from assembling each operation myself. It also puts the proposed change in front of me while I can still stop it.
The work also arrives faster now. Several sessions can make progress independently and then need a decision at once. A patch can be ready for review while a customer conversation raises a new question about the same feature. I have to bring that customer context back to the implementation before we ship it. And sometimes our deploy queue will have five agents that are all waiting to deploy their branches, run QA on staging, and then deploy to production.
The inbox keeps changing what needs doing
Much of the work starts outside the repository. A customer asks for something, an upstream maintainer replies to a patch, or a compliance reminder arrives. Each can change what I need an agent to work on next. I use an email-triage skill in Claude Code for this. It's a set of saved instructions that tells an agent how to read my email threads, summarize what needs attention, and propose actions. I review those proposals before it acts.
It can also forward a message to the agent session already working on that subject. A maintainer's feedback can go to the session working on the upstream patch. A compliance question can go to the session helping with our SOC 2 work. Those agents have the context to investigate or prepare a reply while I move on to something else.
This is a substantial improvement over doing all the research and correspondence myself. AI helps with the business work too, including support, compliance, and working with our accountant. However, I'm still involved in deciding what the messages mean for the business. A customer request may be a bug, a useful feature, or something we should decline. An agent can investigate the options and recommend one. I need to decide what we'll commit to, then make sure the work and the reply agree.
Even the triage workflow needed steering. I had to give it a clear boundary: triage and route the work, then let the relevant session handle the investigation. Otherwise it would offer to take on the follow-up tasks itself and lose focus. Giving an agent a useful job has involved figuring out where that job should end.
As I write this, all my email inboxes are empty, there's nothing waiting in Intercom, and none of our Sentry projects has an unresolved error. I used to reach that point occasionally in the past, but the messages and issues would always pile up again immediately and I would just get burned out trying to stay on top of everything. For about a month now, with AI helping me work through everything, I've finally been able to keep up.
That feels like a big change. I'm shipping more while keeping up with support and any problems that show up after we ship. There haven't been that many problems in production either. We're on top of all of our logging and errors, AI agents have been doing an amazing job at reviewing code before it gets deployed, and DocSpring is running very smoothly.
I'm a solo founder and DocSpring is a relatively small startup, so it always felt weird to call myself a "CEO" as an official title. But now I actually feel like the title fits me better than ever. I've been delegating a lot of my work to AI agents while mostly making executive decisions. I still feel like I'm a builder and that I'm contributing to the code and the architecture, but I'm also spending a lot more time working "on" the business instead of "in" it.
How a calendar fix became a date-parser project
Keeping all these sessions aligned can go wrong, though. A recent fix to our date calculations is a good example of what still lands on my desk. We had a bug in a feature that calculates the difference between dates. The initial version used an average year length to calculate someone's age, which could give the wrong answer around a birthday. The fix was to count calendar years properly.
During AI code review, an agent found another problem nearby: a date with a two-digit year could mean one thing in the browser and something different in the generated PDF. Making the two agree sounded reasonable, so the agent added a fix, then sent the changes through more review.
Over successive rounds, the supported formats expanded from numeric dates with two-digit years to month names. Eventually the agent was adding special handling for values like 07MAY24 and 7th May 24, with tests for the new behavior.
I had already discussed this earlier in a few different AI sessions. API v2 deliberately validates dates strictly. We'd planned a narrow compatibility concession for two-digit years in API v1. Teaching the shared parser and forms to interpret more ambiguous dates went against that decision. The agent hadn't checked those earlier discussions. Each review found another inconsistency, and each fix made the increasingly permissive parser more consistent. The original task was just to calculate an age correctly.
I had approved lists of proposed fixes along the way, but if I'm being honest, I hadn't paid close attention to every suggestion. The date changes appeared in those lists as bugs to fix, without making clear that they changed the product's intended behavior. By the time I questioned why we were supporting 07MAY24 at all, the branch was already on staging. We removed the extra parsing before it went to production and kept the simple calendar fix.
That's an uncomfortable kind of mistake because there was plenty of review. The agents were finding real differences in behavior and writing tests to cover them. But they had lost track of which behavior we actually wanted and got stuck in a feedback loop where they kept going down rabbit holes and handling more and more edge cases. More rounds of the same review kept carrying the work further in the wrong direction. GPT-6 Astra is particularly bad at this when I use Codex for code reviews. All of the findings will be "real" to a certain extent, but it will often bring up extremely niche edge cases that would almost never happen in production.
What still comes back to me
None of this proves that DocSpring is safe from competition. I'm working very hard, but we all have access to the same frontier AI models and coding harnesses. Being busy isn't evidence that customers will keep choosing us, and a new competitor can use agents for operations as well as code. We still have to build something people want to pay for.
I also don't know how long this division of work will last. Better context sharing could reduce the coordination I do between sessions. And models may get much better at the judgments I'm currently making myself. I usually accept around 90% of the default recommendations that they propose, but that last 10% is still important to keep them from getting stuck in feedback loops and going off the rails. And from time to time, I still catch Opus 5.5 making terrible decisions that would harm performance, or designing a system in completely the wrong way.
For now, I still have a business to run. I can hand much more of that work to AI agents, but I still follow it through, decide what we're going to promise customers, and sometimes stop an agent from going down too many rabbit holes. I'm enjoying it, though, and I don't miss the act of programming too much. I still love programming, but I think I love building things more. My backlog finally feels achievable, and I'm looking forward to seeing how far we can get.
