A few months ago I sat down and described a broken process to an AI, piece by piece, until it wasn't broken anymore. I'm not a developer. I didn't read documentation. I just refused to stop until the thing actually worked. This is the story of that process — what it replaced, what it took to build, and the three separate times it broke in ways that made the final version better.
The problem
Part of my job involves collecting the same kind of repetitive information from a group of people, on a regular schedule, and turning it into a finished document that has to go somewhere else for approval. Think: expense-style reporting. Everyone fills something out, attaches proof of what they spent, and it all needs to land in a consistent, complete format — not five slightly different versions that someone then has to clean up by hand.
That "someone" was me.
Everyone wanted to help, but when there's not one consistent format each person's info was just a little bit off. Every submission had 2-3 things to correct. Sometimes involving a back and forth email chain requesting info and waiting on the response.
The first fix was simple: a basic online form that at least got everyone's submissions into a consistent shape and emailed to me automatically. That alone cut my own processing time by roughly half to two-thirds. It was a real improvement. It also had a hard ceiling — it could collect information, but it couldn't think. It couldn't look at what someone submitted and decide whether it was actually complete. It couldn't assemble anything. It just handed me a pile of slightly-more-organized raw material and I still did the rest by hand.
Why I didn't just buy something off the shelf
Whatever I built had to live inside tools my organization already trusted. That ruled out a lot of otherwise reasonable options — new software means procurement reviews, security reviews, and a price tag, and none of that was going to happen for an internal process serving a couple dozen people. It had to be free, it had to work on a phone in a parking lot, and it couldn't require anyone else to install anything or sign up for anything new.
That combination — free, already-trusted, zero new sign-ups — pointed toward building something custom inside the Workspace/Office ecosystem the organization already used, rather than adopting a new product.
How it actually got built
Here's the part I want to be honest about, because I think the honest version is more useful to other non-engineers than the impressive-sounding one: I didn't teach myself to code. I sat down with an AI assistant and described the problem — what the people submitting needed, what the final output had to look like, what was breaking in the old process — and we built it together, piece by piece, testing it against real submissions the whole way.
My job in that process wasn't writing syntax. It was staying relentlessly clear on what "done" actually meant, and refusing to accept an answer that technically worked but didn't solve the real problem.
I wanted to sometimes yell at the computer because it kept suggesting answers that either didn't solve my problem, or solved it, but in a way that our users wouldn't be able to access or input info.
This is where my problem solving skills were put to the test and stretched to the limit.
I think that's the actual skill that mattered here, more than any programming knowledge would have: knowing the process well enough, and caring about it enough, to keep saying "not quite" until it was actually right.
It wasn't a straight line — three real breaks
None of this worked perfectly the first time. Three separate failures stand out, because each one taught me something I wouldn't have known to ask about in advance.
1. The attachment that claimed to exist but didn't
Early on, a real submission came back and something the person had attached wasn't actually in the finished document. The tool had technically logged that a file existed — it even wrote a line saying so — but it had never actually embedded or attached it anywhere. It was a confident, specific, completely false claim. That's a special kind of dangerous bug: not a crash, not an error message, just quiet, plausible-looking data loss.
The fix wasn't a patch — it was a rule change. Now nothing can be marked as "included" unless the system can prove it actually embedded the file, and every attachment gets its own dedicated page in the final document instead of a thumbnail or a link that can quietly go stale.
Yeah it did seem like at this moment that the solution was going to work in theory, but not in real live situations.
2. The link that looked fine and did nothing
I tried to build a simple companion page linking out to the tool — logo, a button, one clear call to action. It rendered beautifully on the first platform I tried. Then I clicked the button. Nothing happened. I tried a second platform. Same result: looked perfect, dead on click. It took a third attempt, and a fair amount of research into how each platform actually sandboxes embedded content, before I landed on an approach using that platform's own native building blocks instead of injected custom code — which turned out to be the one thing that reliably kept links clickable.
Was I going crazy? Was it me? The browser? The User? Was it me again? I can't accurately convey how frustrating it is to not be able to figure out why something isn't working.
3. The instructions that quietly fell out of date
I'd built a step-by-step guide early on to help people use the tool. Then the tool kept improving — which was good — except the guide didn't improve with it. It was still showing an older version of the interface by the time I actually looked at it again. The fix was less "patch the guide" and more "stop hand-maintaining it" — I rebuilt the process so the guide gets generated fresh from the real, current version of the tool every time, instead of being a snapshot that quietly rots.
What it does now
The finished version handles the things that made the old process so heavy by hand: it knows who's submitting and fills in what it can predict, it enforces that nothing gets submitted incomplete (no more chasing someone down after the fact for a missing attachment), it turns multiple file types into a single consistent finished document automatically, and it delivers that finished document the moment someone hits submit — no manual assembly step left for me to do at all.
The actual takeaway
I started out trying to build a slightly better form. I ended up with a process that takes fewer touches from everyone and produces a better result than the original had. What we ended up with: a free, mobile-friendly tool that auto-fills each traveler's home office, handles multiple trips per submission with address auto-fill, requires a receipt on every expense before it'll let you submit, and emails a submission-ready packet the moment someone hits Submit.
It's all built out using a google script in a web app (which I did not know was a thing before this), and it assembles it all seamlessly. I started out building a form, and came away with a process that takes less touches and accomplishes more.
Have you ever started to solve a problem and get a much better solution than you set out to find?
Top comments (0)