Template Studio
For years, our document builder had been holding back the business. Customers couldn't manage their own agreements, complex documents required manual workarounds, and a growing implementation operation and constant gen intervention was needed to keep everything running.
I took ownership of replacing it. Starting with a proof of concept built in two days, I used Claude Code as my implementation partner to turn years of accumulated product knowledge into a working, customer-validated product and engineering-ready handoff in four weeks.
Explore the working prototype
TIMELINE
4
Weeks
TEAM
3.5
Me (+AI), PM, CS
Before
After
The business had digitized the paperwork, not the process.
Getting customers' existing agreements onto our platform was a significant undertaking. They sent over PDFs or images of each page, our team then uploaded them and overlaid fields to enable electronic signing. But the underlying documents remained static. They couldn't adapt to different resident scenarios, devices, calculate values or be easily maintained by customers.
Getting customers through this initial process required significant hand-holding from our implementation team. And once their documents were uploaded, they still depended on us to make changes.
No self-service: Customers couldn't independently create or maintain their own agreements, despite it being part of the product promise.
Operational dependency: A part-time document-building operation handled customer requests through emails, calls and manual revisions.
Fragile workflows: No meaningful versioning meant changes could affect live templates and active customer workflows.
Limited flexibility: Static PDFs, rigid signer roles and missing conditional logic couldn't support increasingly complex resident and family scenarios.
Commercial risk: Competitors offered greater document control, contributing to lost customers and missed opportunities.
I'd spent two years seeing these problems firsthand through customer conversations, support trends, churn reasons, usability testing and the operational strain on CS and document builders.
It was clear that another round of incremental improvements wouldn't solve the underlying problem.
My goal: the prototype is the product.
Rather than create another design specification and wait for engineering capacity (unlikely with a 2-person dev team), I decided to prove the direction by building it.
One day to a working proof of concept.
I put the initial version in front of my Product Manager after 8 hours of building. Seeing the experience working changed the conversation from what we could build to how we could get there.
I continued developing it, making a deliberate decision that the prototype would become the product; not something engineering would have to recreate later.
Working directly in our main repository with Claude Code also meant I could fully understand the existing architecture and map out a practical engineering handoff as I built.
One builder. Two document models. A much bigger opportunity.
The solution wasn't simply a better editor and experience. It needed to support the legal, operational and customer realities of senior living while creating a path toward customer-owned document management.
Flowing Forms: one document, multiple scenarios.
I introduced a live-text document editor with inline, data-linked fields, conditional sections, calculated fields and flexible signer roles.
Instead of maintaining separate templates for every variation, customers could build one dynamic agreement that adapted to the resident's circumstances.
This addressed some of the most persistent customer requests, including conditional signatures, required-if rules and calculations that staff had previously performed manually.
Fixed Forms: meet customers where they are.
Legal and regulatory research uncovered an important requirement: certain official state forms must retain their exact prescribed layout.
Rather than force every document into a flowing format, I introduced Fixed Forms. Allowing customers to upload official PDFs, map their fields to the data library and preserve the original document layout.
This was also a deliberate adoption strategy. Customers could bring their existing fixed documents into the new builder first, then progressively adopt flowing documents as they became comfortable with the additional flexibility.
We didn't make customers choose between the way they work today and where the product needed to go tomorrow.
Flexible roles and signing rules.
The old system relied on rigid assumptions about who signed a document.
I introduced a generic role model of Party, Representative, Staff and Other with configurable requirements such as "at least one of" and "always".
This supported more complex signing arrangements without hard-coding the product around a single resident or customer type.
Designed around the legal and human realities.
Some of the most important decisions weren't about the editor itself:
Paper signing remained a first-class option, with room for handwritten responses and no additional wording that could change the customer's agreement.
Preview used sample data rather than real resident information.
Pre-filled values appeared as plain text to signers, avoiding confusion about what they needed to complete.
Required and optional fields used different levels of the same highlight colour, avoiding reliance on colour alone.
Regional field types and validation supported US and UK requirements.
Signing phases were standardised: prepare, external signers, then community staff.
The goal behind these decisions was simple: make complex documents flexible without making them unpredictable.
AI accelerated the build. Product judgment directed it.
I wasn't using AI to generate a visual prototype. I was using it to build working software.
I owned the product decisions, architecture direction, behaviour, scope and requirements. Claude helped translate those decisions into implementation plans and code through Claude Code.
My process had four guardrails:
Responsibility
Architecture
Implementation
Quality
Data integrity
Approach
Investigated the existing codebase and challenged approaches that introduced unnecessary complexity or future limitations.
Reviewed plans before code was generated, working in small, controlled iterations.
Replaced brittle checks with end-to-end journeys testing actual user behaviour.
Introduced safeguards to protect saved data and prevent unsafe changes.
I also verified that new automated journeys could actually catch failures by deliberately breaking the behaviour they were designed to test.
AI made the implementation faster. It didn't make the decisions for me.
Validate against real customer problems.
I shared the working product with internal team members through a staging link, gathering feedback and rapidly addressing workflow inefficiencies.
For customers, I ran tailored walkthroughs with 10 users, demonstrating scenarios they'd struggled with in the existing builder or had specifically requested.
The feedback reinforced the direction and helped shape subsequent iterations.
From duplicate agreements to dynamic documents.
A customer described maintaining separate packets for joint and individual residents. They immediately recognised the potential of conditional documents to eliminate that duplication.
"The ability to just have one packet that's dynamic would be so much nicer."
From manual calculations to calculated fields.
A customer explained how staff regularly reached for calculators to work out estimated monthly charges. A frustration that had persisted for nearly three years.
From compliance concerns to greater confidence.
Following a walkthrough, a customer explained that the new approach actually closed existing compliance concerns by producing documents appropriate to each resident's circumstances.
From document management to a bigger commercial opportunity.
One customer identified the potential to replace their separate contract lifecycle management software, valued at approximately $30k–$200k annually, with a few additional capabilities.
Internal feedback was equally strong. CS described the product as professional and a solution to pain points for both customers and the internal team.
The confidence in the new direction was enough for CS to recommend pausing migrations to the old builder rather than introducing customers to two versions in quick succession.
Current Customer
"I am so impressed with how quickly you built this, this could entirely replace another tool we currently have to pay for separately — when can we get it?"
The outcome: a new foundation for the business.
Four weeks of active development took Template Studio from proof of concept to a working, customer-validated product, ready for engineering handoff.
The bigger outcome was strategic.
A more scalable business model
Created the foundation for customers to manage their own templates instead of relying entirely on manual document-building support.
A stronger reason to stay
Moved the platform beyond uploaded paperwork and electronic signatures toward ongoing document creation, management and maintenance.
A new commercial opportunity
Opened possibilities for self-service, managed-document services and broader contract lifecycle capabilities.
A different way of building
Demonstrated how AI-assisted development could bring product strategy, design and implementation together without waiting for a traditional design-to-engineering handoff.
Takeaways
The biggest lesson was that AI doesn't replace product judgment. It increases how much of that judgment you can turn into working software.
Two years of accumulated customer and operational knowledge gave me the context to move quickly without building blindly. Treating the prototype as the product meant architecture, quality and implementation had to be considered from the start.
Most importantly, this wasn't about proving I could build something with AI. It was about taking a problem the business had lived with for years and finally making the solution real.