We built PrintPlanr because we were frustrated. Not with our clients — with the software available to them.

In the late 2000s, Infomaze was building web-to-print solutions for clients in the UK printing industry. The front-end ordering experience — customers configuring print jobs online and placing orders — was evolving quickly. What hadn't evolved was the back end. Once an order was placed, print companies were managing production through a combination of desktop MIS software, spreadsheets, and institutional knowledge held by key people who had to be in the building for anything to move.

The desktop print MIS vendors were struggling. Some were on software that hadn't been meaningfully updated in years. Others had enterprise solutions priced for large commercial printers and inaccessible to the mid-market. The cloud was obviously where this needed to go — but nobody had built a proper cloud-native print MIS that understood how the industry actually operated.

We did.

The gap we kept running into

The pattern appeared across multiple clients. We'd build a web-to-print front end — job configurator, product catalogue, online ordering — and deliver it. The client was happy with the front end. But then we'd see what happened to orders after they were placed. Manually re-entered into desktop software. Emailed to production managers. Tracked in spreadsheets. Chased by phone.

The efficiency gained on the ordering side evaporated on the production side. The digital front door opened into an analogue back room.

// What existed vs what the industry needed

What existed

Desktop MIS — installed on a single machine, no remote access
Vendor support becoming unreliable as companies struggled
No native web-to-print integration
Enterprise solutions priced for large commercial printers only
No understanding of print-specific workflow — press codes, colour profiles, production routing
Data locked in desktop databases — no reporting, no visibility

What was needed

Cloud-native — accessible anywhere, any device, no installation
Web-to-print integration — orders from the front end feed directly into production
Print-domain workflow — production codes, press matching, colour management
Multi-user — estimators, production managers, accounts all working in the same system
Reporting and visibility — not just job tracking but business intelligence on production
Priced for mid-market — not only accessible to large commercial printers

The gap was obvious. The question was whether to recommend clients wait for someone to fill it, or fill it ourselves.

The decision to build

✦ Why we decided to build it ourselves
Three things converged. First, we had deep domain knowledge of print workflows from the client work — we understood the production process, the terminology, the specific technical requirements of press scheduling and job costing. Second, we had the engineering capability to build cloud-native SaaS — we'd been building web applications since 2002. Third, the market gap was real and the timing was right — cloud adoption was accelerating, the desktop vendors were visibly struggling, and the mid-market was underserved. We weren't going to build a generic project management tool and skin it for print. We were going to build a print MIS that actually understood print.

The decision wasn't made in a single meeting. It accumulated over several client engagements where we kept hitting the same limitation and kept thinking "someone should build this." At some point we stopped saying "someone" and started saying "us."

What V1 actually looked like

The first version of PrintPlanr was narrow by design. Not because we didn't know what else it needed — we had a long list of requirements from client conversations. But because we understood from building for clients that a product that tries to do everything in V1 ships late, ships broken, and ships without the real-world validation that tells you which of those features users actually need.

V1 did three things:

  • Job creation with print-specific attributes. Not a generic "task" with custom fields. A print job — with production code, substrate, colours, quantity, press assignment, and the production routing that print companies actually use.
  • Production tracking through stages. Prepress, print, finishing, dispatch. Each stage with the specific status options that matter in a print workflow — not generic "in progress" and "done."
  • Basic invoicing. A job completed should produce a document the client can send. Not full accounting integration — just the ability to generate an invoice from a completed job.

That was it. No customer portal. No press scheduling optimisation. No reporting dashboards. No supplier management. No API. All of those came after we had real customers telling us which ones they needed first.

The discipline that made PrintPlanr successful was the same discipline we now apply to every client SaaS we build: V1 is the minimum that gets a real user through a real workflow. Everything else is post-launch.

The evolution to top 10 globally

// PrintPlanr — from V1 to top 10 global cloud print MIS
2010
V1 — Job creation, production tracking, basic invoicing
Narrow scope. First real customers. First real feedback.
2012
Customer portal, supplier management, reporting layer
Built from what early customers said they needed. Not what we assumed they'd want.
2014
Web-to-print integration API, press scheduling, estimating engine
The features that differentiated PrintPlanr from generic job management tools.
2016–2020
International expansion — customers across UK, AU, US, NZ
Cloud delivery meant geography was never a constraint. Customers in three continents, supported from Mysore.
2022
Mobile app — production floor status updates from the press
React Native app for production staff to update job status without returning to a desktop terminal.
2024–now
AI layer — custom MCU training infrastructure
Built proprietary model training infrastructure. AI in production: press recommendation, auto job coding, product suggestions, customer self-service chatbot.

The AI chapter — and why it was built differently

When we decided to add AI to PrintPlanr, we made one decision that shaped everything else: we would not send client data to a third-party AI API.

PrintPlanr handles sensitive business data — job costs, client relationships, pricing, production capacity. A print company's job history is a map of its commercial relationships, its pricing strategy, and its production capability. Sending that data to a generic AI model run by a third party wasn't something our customers would accept — and frankly, it wasn't something we were comfortable with either.

So we built the infrastructure to train our own models on the platform's own data. Custom MCU server infrastructure that keeps every customer's data within the PrintPlanr environment. The models train on PrintPlanr's accumulated production data — not on generic internet text. That makes them better for print-specific tasks and keeps data where it belongs.

Live
Press recommendation engine — suggests the optimal press for each job based on substrate, quantity, finishing requirements, and press availability. Built on production history from thousands of real jobs.
Live
Automatic production code creation — generates the correct production code from a job description. Eliminates a manual step that required specialist knowledge and caused errors when that specialist wasn't available.
Live
Auto-suggestions for job descriptions — as a job is being created, the system suggests completion based on similar jobs. Speeds up job entry and reduces description inconsistency.
Live
Product recommendation engine — suggests related or complementary products to customers based on their order history and browsing behaviour.
Live
AI customer self-service chatbot — handles common customer enquiries about job status, pricing, and product information. Reduces support load without losing the personal service that print customers expect.

What building and running PrintPlanr taught us

01

Domain depth is the product's moat

PrintPlanr is in the top 10 globally not because it's technically superior to everything else — but because it understands print workflows at a depth that a generic project management tool never can. Production codes, press matching, colour management, substrate-specific settings. The domain knowledge is what competitors can't quickly replicate.
02

Running your own SaaS makes you a better builder for clients

Every lesson about multi-tenant architecture, subscription billing, self-service onboarding, zero-downtime deployment, and AI integration — we learned it first on our own product. By the time a client asks us to build these things, we've already made the expensive mistakes on our own account. The benefit flows to clients.
03

Real users surface problems that testing never finds

V1 had edge cases we hadn't anticipated despite years of industry experience. A print company in New Zealand had a press configuration we'd never seen. A large commercial printer had a workflow that didn't fit our production routing model. Real users expose reality. No amount of internal testing replicates it. Ship to real customers as early as the product is viable.
04

The V2 feature list comes from V1 usage — not from assumptions

We had a long list of features we planned to build after V1. About half of them turned out to be less important than we thought. Several features we hadn't planned became the most requested. Running PrintPlanr for 15 years has given us deep respect for the discipline of building from real usage data rather than anticipated needs.
05

Support is a product feedback channel

Saif manages PrintPlanr support from Mysore, handling customers from New Zealand to Australia to California across time zones. Every support interaction is a data point about where the product has friction, where documentation is insufficient, and which workflows users find unintuitive. The product improved substantially from taking support seriously as a feedback channel.
06

AI built on your own data is categorically better

The press recommendation engine trained on PrintPlanr's production history outperforms any generic AI recommendation approach for print jobs — because it understands print-specific variables that no generic model was trained on. Domain-specific AI trained on domain-specific data produces domain-specific results. This is now a principle we apply to every AI engagement we build for clients.

Why this matters for clients who build SaaS with us

✦ The compounded advantage
We've lived every decision you're about to make.
When a client asks us to build a multi-tenant SaaS platform, we're not designing multi-tenancy from a textbook. We designed it for PrintPlanr in 2010 and have maintained it through 15 years of growth. When a client asks us to add AI to their product, we're not evaluating which third-party API to wrap. We built proprietary training infrastructure because we understood why generic AI APIs weren't good enough for domain-specific needs.

The expensive mistakes — the architecture decisions that seemed right and proved wrong, the features built before users validated them, the AI approaches that didn't work until the data was right — we made those on our own platform. Not on a client's. The lessons are already paid for.

That's what 15+ products built on our own account produces: a team that has lived every decision the client is about to make, with opinions formed by experience rather than theory.

PrintPlanr will be moving to Infomaze Sphere — our dedicated product company — as we formalise the separation between our services and our products. When that happens, it will carry with it 15 years of engineering decisions, customer relationships, and product learning that started from a single frustration: the software available to our clients wasn't good enough.

We fixed that. And fixing it taught us how to build everything else we've built since.

Want to build something that lasts 15 years?
Free product workshop — we bring 15+ SaaS products of our own to the conversation. Architecture designed to scale. AI built in. The expensive lessons already paid for.