Custom software, built by operators.
Custom SaaS solutions, at Mule, are small custom software projects, internal tools, simple SaaS MVPs, custom integrations between existing systems, built for small businesses that can't justify enterprise-software pricing. Mule operates first-party SaaS products of its own (Mule v1 and the upcoming Nest), so the studio isn't theorising about what's involved in shipping and running real software, it's the day job.
Mule's own SaaS portfolio
Two products, both operated by the same team that ships the studio's client work.
**Mule v1** is an earlier Mule SaaS product running on its own dedicated domain. The split exists because v1's audience and product surface diverged from the marketing studio's surface enough to deserve its own brand and its own customer flow. v1's existence as a separately-operated Mule SaaS is the longest-running proof point that the studio knows how to ship and operate software, not just talk about it.
**Nest** is an upcoming Mule SaaS product currently in development. Details are forthcoming as the product approaches launch. The relevant point for a custom-SaaS conversation: Mule is actively building new software, not winding down, which means the engineering surface is staying current.
What does 'custom SaaS' mean at Mule's scale?
It means small software, not big software. Three kinds of work fit. First: internal tools for small businesses, a custom inventory system for a multi-location retail business, a workflow tool for a small consultancy, a quoting tool for a contractor. Second: simple SaaS MVPs, the first working version of a software product that a founder is testing in market, scoped to validate a single core use case rather than to ship an entire enterprise feature set. Third: custom integrations, connecting two existing systems (a CRM and a billing tool, a booking platform and an accounting system) when off-the-shelf middleware doesn't fit.
What doesn't fit: enterprise-scale custom software, multi-team SaaS platforms with complex compliance requirements, anything that needs a dedicated security team or a 24/7 on-call rotation to operate. Mule is three people; the studio takes on custom-software briefs that three people can deliver well, using the same stack and operating principles that the in-house products run on.
How is custom SaaS priced?
Per brief, computed from the price book rather than guessed. A focused internal tool is the floor; a full CRM platform replacing something like Salesforce or HubSpot sits at the top of the band we publish. See /scale for the exact numbers, which are generated from the same engine that quotes you, so they cannot drift from what you would actually be charged.
What the floor protects: below it there is usually not enough work in a custom tool to do it properly, and the right answer is an off-the-shelf tool, a middleware integration, or a workflow change rather than software. We will tell you that on the first call if it is the honest answer.
On ownership, the same rule as our websites, and we would rather be blunt. Buy the build once and the source code, the accounts, and the deploy credentials are yours on completion. Subscribe with nothing down and Mule owns and runs the software until you buy it out, and the buyout falls every month until it reaches zero. On a heavy tool that lane also carries a data tier, because while we own and host it the database and the traffic are on our bill. Your data is yours on either lane, always.
What are the honest limits, what won't Mule build?
Five things, in plain English. First: anything requiring SOC 2 / ISO 27001 / HIPAA compliance certifications from day one. Mule isn't a compliance-certified studio; if your industry requires those certifications, you need a different vendor. Second: anything requiring 24/7 production support. The studio operates on business hours; production-critical software with overnight on-call needs a different operating model. Third: large-scale enterprise SaaS platforms, anything that would take more than three months of full-team effort to ship. Fourth: software where the customer base would be millions of users at launch. Mule's stack and operating model are calibrated for hundreds-to-thousands of users, not millions. Fifth: ML / AI training infrastructure as the core product. We use AI assistively in our work and in our products; we don't build foundation-model infrastructure.
What's left after those exclusions is still a meaningful surface, and it's the surface most small businesses with software needs actually live in. We'll be honest on the first call if your brief crosses one of the lines.
About custom saas solutions.
Does Mule actually ship and operate SaaS, or is this just custom-build work?
Mule operates first-party SaaS products: Mule v1 (operating on its own dedicated domain) and Nest (upcoming). The studio's engineering team has been shipping and operating software in production for multiple product cycles. Custom-SaaS engagements draw on the same stack, the same deploy infrastructure, and the same operational discipline we run our own products on.
What's the typical timeline for a custom software engagement?
Depends on scope. A simple internal tool with one database, sign-in, and a focused UI typically lands in 4-6 weeks. A small SaaS MVP, billing, multi-user, customer-facing, typically lands in 8-12 weeks. Integrations between existing systems are usually 2-4 weeks. We'll size the timeline in the proposal alongside the fixed price; both move together based on the brief.
Will the software be hosted on accounts in my name?
Same answer as on Mule's websites, which means it depends how you pay, and we would rather say so. Buy the build once and the software, the source, and the accounts are yours on completion. Subscribe with nothing down and Mule owns and runs it until you buy it out, with a buyout that falls monthly to zero; on a heavy tool that lane also carries a data tier, because the database and the traffic are on our bill while it is ours. Your data is yours either way. If you ever switch developers or maintain it in-house, there's no Mule-side dependency to unwind. The same discipline applies to Mule's own products; we know what clean ownership looks like because we set ours up the same way.
What stack does Mule use for custom software?
TypeScript on Node.js for the application layer, Next.js for the frontend, Supabase for database and auth, Stripe for billing, Vercel for hosting and deploys. The choices are deliberate: open standards, no single-vendor lock-in at the language or framework level, infrastructure providers that allow clean export. This is the same stack Mule's own SaaS products are built on, choices battle-tested in production, not just recommended in proposals. We're flexible on individual components if your team already operates on a different stack and the engagement is meant to fit into that.
What happens when the engagement ends, do you maintain the software ongoing?
Optional. The standard fixed-price proposal covers build through launch plus 30 days of post-launch fixes. After that, ongoing maintenance is quoted from your brief () or scoped per engagement. Most small custom-software builds run well on minimal post-launch attention; we'll tell you on the call which way your project leans.
How do I start a custom software conversation?
Email a paragraph to info@mule-digital.com describing what you're trying to build and why off-the-shelf tools haven't fit. Same-business-day reply with either a request for a fifteen-minute scoping call, a recommendation that an existing tool would solve the problem more cheaply, or an honest 'we're not the right vendor' if the brief crosses one of the limits.
Work with a studio that means it.
Send a short brief. Same-day reply. Own it outright from $600, or subscribe from $29.99 / mo with nothing down.