Custom software, built by operators.
Custom SaaS solutions, at Mule, are software products built for a specific business rather than rented from a vendor: SaaS products with billing and accounts, internal tools, customer portals, data platforms, and integrations between systems that were never designed to talk. Mule operates first-party SaaS of its own, so the studio is not theorising about what shipping and running real software involves. It is the day job.
Mule's own software, and the client software we can point at
Two of each, which is the only reason this page is allowed to make the claim in its headline.
In-house, Mule v1 is an earlier Mule SaaS product running on its own dedicated domain, split off because its audience and product surface diverged from the studio's own. Nest is a second Mule SaaS product, built and operated by the same three people who ship the client work. Neither is a side project. Both have real users and real uptime consequences.
For clients, Alpha Solutions is a B2B web platform for an IMO, with an agent tooling dashboard, a product showcase, and carrier portal integrations. Vellum is a marketing site and product UI for a SaaS that powers Independent Marketing Organizations, built around a single keystroke flow. Both are on /work with the detail.
The relevant point for a custom-software conversation is that the engineering surface is current. We are actively building software this quarter, not describing something we did once.
What does 'custom SaaS' mean at Mule's scale?
It means small software, built properly, not big software built badly. Four kinds of work fit.
Internal tools for a specific business: a custom inventory system for a multi-location retailer, a workflow tool for a small consultancy, a quoting tool for a contractor. Customer-facing web apps and portals: a logged-in surface where your customers check status, upload documents, and approve things without emailing anyone. SaaS products: the first working version of software a founder is selling, scoped to validate one core use case rather than to ship an entire enterprise feature set, with accounts, roles, and billing that actually work. And integrations: connecting two systems you already run, a CRM and a billing tool, a booking platform and an accounting system, when off-the-shelf middleware does not fit.
What does not fit: enterprise-scale platforms, multi-team products with heavy compliance requirements, anything needing a dedicated security team or a 24/7 on-call rotation. Mule is three people. The studio takes on briefs three people can deliver well, on the same stack and the same operating principles the in-house products run on.
How is custom software priced?
Per brief, and there is no price list to reverse-engineer your scope from. We stopped publishing prices because a published price is a guess about a business we have not met yet. It makes small jobs look expensive and large ones look impossible, and it quietly pushes every brief toward whichever number was easiest to print. So we ask what you actually need, we price that, and we show you the line items. You get a real number, in writing, from a person.
What drives the number, in rough order of weight: how many distinct things the software has to do, how many systems it has to integrate with, whether existing data has to be migrated and how clean it is, how many user roles need different views and permissions, and whether billing, offline support, or a mobile surface is in scope. Those are the questions on the first call.
There is also a floor below which custom software is the wrong answer, even though we are the ones who would be paid to build it. 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 product, a middleware integration, or a workflow change. 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 will Mule not build?
Five things, in plain English. First: anything requiring SOC 2, ISO 27001, or HIPAA certification from day one. Mule is not a compliance-certified studio; if your industry requires those, you need a different vendor. Second: anything requiring 24/7 production support. The studio operates on business hours, and production-critical software with overnight on-call needs a different operating model. Third: large enterprise platforms, meaning anything that would take more than three months of full-team effort to ship. Fourth: software expecting millions of users at launch. Our stack and operating model are calibrated for hundreds to thousands, not millions. Fifth: machine-learning training infrastructure as the core product. We use AI assistively in our work and in our products; we do not build foundation-model infrastructure.
What is left after those exclusions is still a large surface, and it is the surface most small and mid-sized businesses with software needs actually live in. We will be honest on the first call if your brief crosses one of the lines.
SaaS products
Software you sell to other businesses. Accounts, roles, billing, and the boring parts done right.
Open →Custom software and integrations
Bespoke systems, and making the ones you already run talk to each other.
Open →Web apps and customer portals
The logged-in surface your customers actually use.
Open →Custom business tools
Internal software for the job your team currently does in a spreadsheet.
Open →Data management platforms
One place the numbers live, with a reporting layer on top.
Open →Mobile apps
iOS and Android, when the work genuinely happens away from a desk.
Open →
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, on its own dedicated domain, and Nest. The engineering team has been shipping and operating software in production across multiple product cycles, and has built client software of the same shape, including a B2B platform for an IMO and the product UI for a SaaS sold to Independent Marketing Organizations. Custom engagements draw on the same stack, the same deploy infrastructure, and the same operational discipline we run our own products on.
What is the typical timeline for a custom software engagement?
It depends on scope. A focused internal tool with one database, sign-in, and a clear UI typically lands in four to six weeks. A small SaaS product with billing, multiple users, and a customer-facing surface typically lands in eight to twelve weeks. Integrations between existing systems are usually two to four weeks. The timeline and the quote are written together in the proposal, and both move with 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 is 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, Postgres for data, Stripe for billing, and Vercel for hosting and deploys. The choices are deliberate: open standards, no single-vendor lock-in at the language or framework level, and infrastructure that allows a clean export. This is the same stack Mule's own SaaS products run on, so the choices are battle-tested in production rather than recommended in a proposal. We are flexible on individual components if your team already operates on a different stack and the engagement has to fit into it.
What does it cost to build custom software with Mule?
There is no price list and there are no packages. You describe what the software has to do, we ask a few questions, and a person writes back with a quote and the line items behind it. The number is driven by scope: how many things it does, how many systems it touches, whether data has to be migrated, how many user roles need different views, and whether billing or a mobile surface is in scope. If an off-the-shelf product would solve your problem more cheaply, we will say so instead of quoting.
What happens when the engagement ends, do you maintain the software ongoing?
Optional. A one-time build covers the project through launch plus a post-launch fix window, written into the proposal. After that, ongoing maintenance is quoted from your brief or folded into a subscription. Most small custom builds run well on minimal post-launch attention, and we will tell you on the call which way yours leans.
How do I start a custom software conversation?
Email a paragraph to info@mule-digital.com describing what you are trying to build and why off-the-shelf tools have not fit. Same-business-day reply with either a request for a short scoping call, a recommendation that an existing tool would solve it more cheaply, or an honest 'we are not the right vendor' if the brief crosses one of the limits.
Work with a studio that means it.
Send a short brief. A person replies the same business day, with a quote and the line items behind it. Own it outright, or subscribe with nothing down. On a subscription we own it until the buyout, and the buyout falls to zero.