Software / SaaS Product
Industry: Field Service Management
3-Tier
Tenancy model: power admin, account, tenant admin
In short
NTS Management System is Arcetis's in-house, custom-built multi-tenant SaaS platform that gives service businesses - originally pest control, now generalized to any service vertical - a single branded system for bookings, CRM/leads, invoicing, contracts, and finance. It runs a three-tier tenancy model (power admin, account, tenant admin), resolves each tenant from its own custom domain via a TenantContext class, and scopes every database query to prevent cross-tenant data leakage. Built in PHP 8.1 with a custom MVC and no framework, it is live in production with real client tenants, deployed through a GitHub Actions CI/CD pipeline that smoke-tests every release.
NTS Management System is a product Arcetis designed, built, and operates itself - not a client engagement, but the platform Arcetis uses to prove out its own field-service-operations thesis in production. It began as a purpose-built back office for the pest control industry: bookings, customer records, service visit reports. As Arcetis worked with more service businesses, a pattern emerged - the operational problem of scheduling, customer records, invoicing, contracts, and cash flow looks the same whether a business kills termites, mows lawns, or cleans pools. Arcetis rebuilt the platform's foundation around that insight, stripping every pest-control-specific default out of the codebase and replacing it with per-tenant, settings-driven branding, so any service business - or any operator managing a portfolio of them - can run under its own name, domain, currency, and tax rules, on the same underlying system.
Most service businesses assemble their operations out of five or six separate tools that were never designed to talk to each other: a booking widget bolted onto a website, a spreadsheet or lightweight CRM for leads, invoicing software for billing, a separate e-signature tool for contracts, and yet another tool - or a shoebox of paper - for tracking income, expenses, and tax. Data gets re-keyed at every handoff. A lead generated through a Facebook ad campaign has to be manually copied into whatever CRM the business happens to use. A signed contract lives behind a different login than the invoice it's tied to. Job and inspection reports get typed up after the fact instead of being generated straight from the visit. None of it is unified, none of it is branded to the operator, and none of it scales past a single owner-operator's ability to hold it all in their head. That fragmentation compounds for the kind of business Arcetis increasingly works with: an operator or parent company running several client-facing service brands from one back office, without every brand looking like it's using the same off-the-shelf software. Off-the-shelf field-service SaaS products solve the single-tenant version of this problem well enough, but they're built for one business at a time under one shared login. Hand that same software to an operator managing several client tenants and it has no clean way to keep tenant data - customer records, leads, invoices, financials - from bleeding across accounts, and no way to give each client a system branded as their own rather than a shared, generic tool. Arcetis needed - for its own operational thesis, and for the businesses it works with - a platform that treated multi-tenancy as core to the domain rather than something retrofitted after the fact: a real three-tier structure with hard boundaries between the platform operator, an account layer managing many tenants, and each tenant's own admin users, plus a settings layer so branding, currency, tax rules, and email all belong to the tenant instead of being hardcoded into the application. That became the design brief for NTS Management System.
Arcetis designed and built NTS Management System entirely in-house, from the original pest-control-specific version through its generalization into a white-label, multi-tenant platform. Arcetis's team wrote the custom PHP MVC application from the ground up rather than adopting an existing framework, designed the three-tier tenancy model and the TenantContext-based domain resolution underneath it, and implemented every business workflow in the product - bookings, the leads/CRM pipeline, invoicing, contracts and e-signing, finance and reporting, and email marketing - end to end. Arcetis also built and owns the deployment pipeline: the GitHub Actions CI/CD workflow, the rsync-based release process to the Ubuntu VPS, and the automated post-deploy smoke test. NTS Management System is operated by Arcetis, not handed off to a client, and real tenant businesses run their operations on it in production today.
A bookings module backed by a public REST API, so an external marketing website can submit booking-form data directly into the platform without manual re-entry. Every booking ties back to a tenant-scoped customer record, so a service business's booking history, contact details, and service address live in one place rather than scattered across a website form and a separate scheduling tool.
Field technicians can log service and inspection visits directly against a customer's record, and the platform exports those visit reports as PDFs. That turns a technician's on-site notes into a branded, shareable document the customer or the business can keep on file, without a separate reporting tool or manual write-up after the fact.
A leads/CRM pipeline moves prospects through New, Contacted, Qualified, Converted, and Lost stages, giving a service business one place to track everything from first inquiry to signed customer. A Meta/Facebook Lead Ads webhook importer feeds leads generated through Facebook lead-form ads directly into the New stage automatically, closing the gap between paid lead generation and the sales pipeline.
Invoices move through a draft, sent, paid, and overdue status flow and are rendered as branded PDFs via dompdf. Each tenant's currency, tax label, and tax rate are applied automatically from that tenant's settings, so an invoice generated for one tenant reflects that business's own pricing and tax rules rather than a shared default.
Contracts can be sent to customers through a public signing link that requires no login. When a customer signs, the platform captures the signature itself along with the signer's IP address and a timestamp, producing an auditable record of who signed, from where, and when, without a third-party e-signature vendor in the loop.
A finance module tracks income and expenses, rolls them into a profit-and-loss dashboard, and produces GST/VAT tax summary reports per tenant. The same platform includes email marketing campaign tools and a newsletter list, using each tenant's own SMTP configuration so outbound mail leaves under that tenant's identity.
Every architectural decision in NTS Management System flows from one requirement: many independent businesses, or one operator managing many client tenants, running on a single shared codebase and a single MySQL 8 database, without any tenant ever seeing another tenant's data, and without any tenant's client-facing pages looking like they're using shared, off-the-shelf software. The system is organized around three tiers. At the top is the power admin - a platform-root role that sits above all tenants and can provision new accounts, without belonging to any tenant itself. Below that is the account tier: an operator layer that can own and manage multiple client tenants under one login, built for agencies or parent companies running several service brands at once. At the base is the tenant admin - the day-to-day users at an individual service business, scoped to exactly one tenant and unable to see or act outside it. That three-tier split is enforced in code, not just in the interface: every controller action checks the caller's tier before it checks anything else. Tenant resolution happens at the HTTP layer, before a single query runs. Each tenant is mapped to its own custom domain, and a TenantContext class inspects the Host header on every incoming request to determine which tenant the request belongs to. That context object is threaded through the request lifecycle and used to scope every subsequent database query - customers, bookings, leads, invoices, contracts, financial records - to that tenant's rows only. There is no cross-tenant query path in the application; tenant scoping isn't a filter applied late, it's a condition attached at the point every query is built. That's the difference between multi-tenancy as a marketing claim and multi-tenancy as an architectural guarantee, and it's the piece Arcetis treated as non-negotiable, given that the platform's whole value proposition rests on client tenants being able to trust that their data is genuinely isolated from every other tenant on the box. Branding and configuration live at the same tenant-scoped layer as the data. A settings table drives logo, color, business name, currency, tax label and rate, SMTP credentials, and timezone per tenant, so the login page, invoices, contracts, and outbound email a tenant's customers see are branded to that tenant, not to Arcetis or to NTS Management System itself. This is the direct legacy of the platform's generalization: the original pest-control build had industry defaults - terminology, tax assumptions, workflow labels - hardcoded into the application. Generalizing the platform meant finding every one of those hardcoded assumptions and moving it into tenant-level settings, so the same codebase that runs a pest control company's back office can run a landscaping company's or a pool-cleaning company's without a single code change, only a settings change. Operationally, the whole system runs as a single custom PHP MVC application, no framework, against MySQL 8 via PDO, deployed to one Ubuntu VPS behind Apache with mod_rewrite handling the per-domain routing that makes tenant custom domains work. PDF generation for invoices, contracts, and inspection reports runs through dompdf; transactional and marketing email runs through PHPMailer, using each tenant's own SMTP settings so mail leaves under the tenant's identity rather than Arcetis's. Keeping the whole platform on one server and one MVC codebase, rather than splitting it into services, was itself a deliberate choice: at this stage it keeps tenant-scoping logic in one place, auditable in a single codebase, instead of duplicated across services.
Every tenant in NTS Management System is resolved from the HTTP Host header at request time by a TenantContext class, before any database query executes. That context scopes every subsequent query - customers, bookings, leads, invoices, contracts, financials - to the current tenant only, so there is no code path in the application that can return another tenant's rows. Combined with the three-tier permission model, it means an operator managing several client tenants can trust that each tenant's data and branded front end stay fully separated from every other tenant on the same server.
Contracts can be sent for signature via a public signing link that requires no login on the signer's side. When a customer signs, the platform captures the signature itself along with the signer's IP address and a timestamp, then attaches that record to the contract. That turns a contract into an auditable event - who signed, from where, and when - without adding a third-party e-signature vendor or a separate system of record into the tenant's workflow.
Leads generated through Meta and Facebook Lead Ads forms are imported directly into the platform's CRM pipeline through a webhook, landing automatically in the New stage of the New-Contacted-Qualified-Converted-Lost pipeline with no manual export/import step. Paired with the public bookings API, which lets an external marketing website submit booking-form data straight into the platform, both of a service business's main top-of-funnel channels feed the same tenant-scoped CRM and booking pipeline in real time.
NTS Management System ships through a GitHub Actions pipeline that rsyncs the application over SSH to its production Ubuntu VPS on every deploy. Rather than treating a deploy as complete once files are copied, the pipeline runs an automated smoke test against the live site immediately after each release, confirming the login page actually responds correctly before the deploy is considered successful. That closes the loop between code shipped and product actually working in production, and it's a pipeline genuinely in active use, not just documented.
Tenancy model: power admin, account, tenant admin
Lead pipeline, New through Converted/Lost
Technology used
Key learnings
Building NTS Management System in-house, rather than adapting existing field-service software, taught Arcetis something that now shapes how it scopes every custom platform: the cost of multi-tenancy is almost entirely upfront, in the data model, and nearly impossible to retrofit later. Deciding early that every table would carry a tenant scope, and that resolution would happen once at the request boundary through a single TenantContext rather than scattered permission checks, meant tenant isolation was a property of the architecture rather than a habit developers had to remember. That discipline paid for itself again during generalization: because industry assumptions were the only thing hardcoded, turning a pest-control tool into a platform for any service business was a settings and defaults migration, not a rewrite. The other lesson was about deployment discipline. Running production infrastructure for real tenants, rather than shipping a client's project and moving on, meant a broken deploy was Arcetis's incident, not a support ticket for someone else to file. That's what drove the automated post-deploy smoke test: a deploy isn't done when the files land on the server, it's done when the pipeline has confirmed the live login page actually responds. Operating that discipline against its own product gives Arcetis a sharper, first-hand answer in every client conversation since about what a genuinely production-grade CI/CD pipeline needs to check.
NTS Management System is Arcetis's in-house, custom-built multi-tenant SaaS admin platform for service businesses. It gives a service business, or an operator managing several client tenants, one branded system for bookings, leads/CRM, invoicing, contracts, and finance, instead of stitching those together from separate tools.
Each tenant is assigned its own custom domain. A TenantContext class reads the HTTP Host header on every incoming request to identify the tenant, and that context scopes every database query for the rest of the request to that tenant's data only, so there is no path in the application that returns another tenant's records.
Any service business. It was originally built for pest control, then deliberately generalized: hardcoded, industry-specific defaults were removed and replaced with tenant-level settings for branding, currency, tax label and rate, and timezone, so the same platform can run a landscaping company, a pool-cleaning company, or any other service business under its own brand.
It's live in production. Real client tenants run their operations on it today, and every release goes through a GitHub Actions CI/CD pipeline that automatically smoke-tests the live login page after deployment before the release is considered complete.