MHC INTERVIEW
How Software Platforms Outgrow DIY Document Generation
MHC Host
Sharon Jones Malloch, Head of Content Marketing at MHC
Guest
Jamie Harris, Senior Account & Partner Executive at MHC
June 30, 2026
Document generation often starts as a practical product need. A customer needs a report, contract, statement, notice, or other communication, and the software team finds a way to produce it with the tools they already have.
That approach can work well at first. But as customers, templates, data sources, business rules, delivery channels, and compliance requirements grow, document generation can become harder to manage. Over time, what began as a simple output process often turns into a larger infrastructure challenge tied to customer experience, implementation, support, and scale.
In this Expert Insights conversation, Jamie Harris explains how software teams can recognize when they’ve outgrown a DIY or patchwork approach to document generation. He shares why building the first version is different from maintaining many variations, what happens when teams hit the scaling wall, and how a more purpose-built approach is needed to manage templates, data, workflows, approvals, accessibility, auditability, and delivery with greater control.
You’ll Learn:
- How document generation typically starts inside software platforms
- Why the first version often works until customer and product variation increases
- What happens when document generation hits the scaling wall
- Why building document generation is different from maintaining it over time
- What warning signs may indicate that your current approach is no longer enough
Key Takeaways
- Document generation often begins as a practical response to an immediate customer or product need.
- As platforms scale — managing more customers, templates, data sources, rules, exceptions, and delivery channels — the process becomes harder to manage.
- Open-source, DIY and patchwork approaches are not automatically wrong, but they can become harder to maintain, document, govern, and scale as requirements grow.
- In regulated or high-stakes environments, communications may need stronger controls around approvals, accessibility, auditability, version control, and data governance.
- Warning signs a platform has outgrown its DIY approach includes: engineering required for every template change, manual testing and approvals, unexpected failures, customer-specific workarounds, and the product teams saying “no” or “not yet” to document-related requests.
Meet the Host and Guests
HOST
Sharon Jones Malloch
MHC Head of Content Marketing
Read the bio
Sharon leads content marketing at MHC, overseeing strategies that fuel sales and demand generation. With more than a decade of experience in customer communications, Sharon brings deep insight into customer pain points, industry trends, and the critical role of solutions in managing regulatory communications. Before joining MHC, she honed her marketing expertise at Doxim, Messagepoint, and OpenText.
GUEST
Jamie Harris
Senior Account & Partner Executive at MHC
Read the bio
Bob Johnson is Executive Vice President at Odessa, a provider of technology solutions for auto and equipment finance organizations. Odessa supports lenders across the full lending lifecycle, including origination, servicing, and portfolio management.
Want to Read Instead of Watching the Video?
Below is the complete transcript from this Expert Insights session with Sharon Malloch and Jamie Harris.
Use the accordion sections to expand and explore the discussion in detail.
Q1: How does document generation typically start inside a software platform?
Sharon: I suspect most teams managing a software platform don’t set out to build full document generation infrastructure from the start. What does it look typically like when document generation begins within a software platform?
Jamie: It usually starts with a real customer or product need. A customer needs a document, communication, report, statement, or other output, and the team uses whatever tools they have on hand to meet that need as quickly as possible. The first version works well enough and gets the job done. But then another customer asks for something slightly different, and the scope begins to creep and expand.
Q2: What challenges appears when teams try to scale document generation?
Sharon:
So, they start from a very practical place, but eventually what worked initially starts to create friction as the platform grows. What are some of the pain points that appear?
Jamie:
The friction starts when the implementation becomes more complex. At first, the requirements are simple and linear. It may be a one-time, limited need. Then it becomes many customers, many rules, many templates, and many exceptions.
The same process that once worked and met the need can start slowing the team down. It is rarely one major failure. It is more like death by a thousand paper cuts.
A template change takes longer. A customer needs a variation the system was not designed to support. Data comes from different places and does not map cleanly. Data changes are one of the most complex things in communication and document management, because systems can fail if the data is off by even one character, depending on how it is structured.
Ownership issues also start to appear. Who owns the change? Who is supposed to test it? Who manages quality control? Testing becomes time-consuming and manual. Version control becomes messy or even non-existent. Customer-specific logic becomes buried in code.
That is when the team realizes document generation is no longer a small feature. It affects delivery, support, and most importantly, the customer experience.
Q3: What is the scaling wall?
Sharon:
Let’s talk about the scaling wall. A company may have an approach that works for 10 customers, or 50 customers, or one product line. But then growth exposes the limits. What starts to break when a software platform tries to scale document generation?
Jamie:
As you add more customers, you create more variations. As you add more verticals, you create more requirements. Once you have to integrate with other systems of record, that creates significant complexity. You may need to get customer data from one place or another place. You may need to update data in one system or another system. You have all of these interactions happening across the process. Compliance requirements also come into play — not just the requirements you have today, but what is coming down the road.
So, if you are relying on manual reviews, custom work, or engineering tickets to keep up, then you are already behind. That slows implementations, delays customer requests, and makes the platform harder to scale.
The system that worked at one stage may no longer work at the next stage because it has become too big and too complex. The broader lesson is recognizing when document generation has become infrastructure within your organization.
Q4: How is building document generation different from maintaining it?
Sharon:
Software teams are comfortable building. It’s part of their DNA. They are used to saying, “We can build that.” But how should teams decide when document generation is no longer something they should continue building internally, and instead has become infrastructure that needs to be managed more deliberately?
Jamie:
Technical teams can certainly build document generation. They can build something that works for a set of requirements.
The problem comes when the scope gets out of control and document generation is no longer a side thing they are doing. It becomes a core thing they have to manage. The challenge is whether they are really designed or set up to manage that process long term, especially when communications become high volume and highly variable.
Building the first version is very different from maintaining hundreds of versions, and in some cases thousands of versions. Product teams have to consider scale, performance, data variability, workflow, approvals, accessibility, auditability, change management, and customer-specific needs.
Teams may end up spending valuable engineering time maintaining what has become a platform inside their system. At that point, they have to ask whether this is really a core competency and whether it is the best use of their time.
In the long run, they may need something engineered specifically to manage this type of customer communications challenge.
Q5: Why isn't open source the problem — and why do regulated environments raise the stakes?
Sharon:
A lot of companies use open-source libraries, custom code, or a mix of internal tools to handle document generation. And as you said, that can work for a while. How do you talk about the limitations of that approach for regulated customers without making it sound like open source or custom code is the problem?
Jamie:
Open source is not the enemy. Custom code is not automatically wrong. Teams are doing what they need to do to meet a customer need, so this is not about slap someone’s wrist for how they’ve solved the problem.
But, the problem comes when the approach needs to scale and requires greater documentation and control. In regulated industries, organizations need a clear view of all templates, rules, versions, data, and approval steps. Those things are important because they help manage risk as it relates to compliance.
Approval workflows matter. Auditability matters. Accessibility matters. Version control matters. Data governance matters.
A document is no longer just a document. It is not just an output. It can become evidence of what was communicated. Once you reach that point, the conversation should be about maturity: how to improve the system, manage all of the required components, and make the process meet the needs of the business.
Q6: What changes when teams move to a purpose-built document generation approach?
Sharon:
Let’s bring this back to the solution side. When a software team moves from a patchwork or custom-built approach to something purpose built, what are the biggest changes they see?
Jamie:
The biggest change is that everything becomes more centralized. Templates, logic, and change management can all be managed in a more consistent way.
You might also be able to give business users the ability to manage and update certain content changes without requiring engineering to get involved every time. After all, a purpose-built approach can support more variation without creating more manual work. So you might see your engineering teams able to focus on their expertise within the core product, instead of maintaining something that may not be a core capability.
Essentially, the company gains more control, consistency, and scalability across the entire document generation process. That creates a stronger internal infrastructure, gives teams a better way to support customer-specific needs, and helps improve the customer experience.
Q7: What warning signs show the software platform has outgrown its DIY approach?
Sharon:
For people listening to this who are part of a product team, why don’t you share a few warning signs that they might have outgrown their current document generation approach?
Jamie:
If every template change requires engineering to be involved, that is a warning sign.
If unexpected failures keep popping up because data changed or something else changed, that’s an important warning sign.
If product teams are saying “no” or “not yet” to customers because a change is going to break something in the infrastructure, that is also a warning sign.
And if you are doing things manually all the time, you probably need to start looking at what you are doing. If testing, auditing, quality control, and approvals are all manual, you need to take a closer look.
If you are waiting until everything falls apart to recognize that you have a problem, I would recommend not doing that. Look for those warning signs early. If you see them, it may be time to evaluate whether there is a better way.