DroneService Pro Roadmap

The thing you sell and the thing you build are different levels, and keeping them apart is what lets new industries arrive without forking anything.

• Platform. DroneService Pro. The records every tool shares: Operator, Company as a tree, Work Order, Asset, Person. Billing, permissions, events, and the API. Nothing industry-specific lives here.
• Tools. The unit you build. A tool owns its tables, API, screens, permissions, and events, and is written once. A map viewer, a plan overlay, a GCP planner, a chemical inventory, a work order system.
• Modules. The unit you sell. A module is a curated bundle of tools plus the vocabulary, defaults, templates, and workflows for one type of work. Mostly data, not code. AeroRev already works this way with its industry packs.

Three rules that keep the overlap clean

• A tool is installed once per operator. If two modules include the same tool, there is one copy. Each module contributes a configuration: which facets are on, default layers, terminology. Same code, different faces.
• Entitlements resolve to tools. You sell modules; the platform computes the union of tools those modules grant. A tool can also be sold alone as an add-on, so a Construction operator can buy 3D Captures without the whole Survey and Mapping module.
• Vocabulary is a module layer over platform names. The database always says Company and Work Order. The module says Project, Site, Field, or Asset for a company node, and Capture, Session, Visit, or Application for a work order. It is also how the rule that customer-facing copy never says "survey" becomes a setting instead of a code review.

Two consequences follow. A direct client company buying only Construction is an operator with one module and no Business module, which is exactly the Operator Model's direct case. And the existing code maps onto this without inventing anything: DroneVision is the Construction module and most of its tools, DSP is the Business module, and the imapshit tools are tools that several modules will share.

The Operator Model from September 4 is adopted with its vocabulary and two changes. The first covers a company that comes in on its own and only wants DroneVision. The second replaces the model's flat companies with per-project user restrictions by a company tree, where membership at a node covers everything below it.

One tree of companies, one kind of work

Below the operator there are only two records that matter: a Company, which nests, and a Work Order, which hangs under a company node. A mining producer with six pits reporting to one manager is one parent with six children that inherit its billing and contacts. Another producer with ten pits that each have their own manager, billing, and deliverables list is one parent with ten children that override them. Same records, different tree.

The rules that make the tree work:

• One record type, any depth. A node is a company, a region, a site, a project, or an asset depending only on where it sits and what the module calls that level. Every node can carry an address, a boundary, and coordinates; a "site" is simply a node with geometry.
• Everything inherits down unless overridden. Billing contact, safety contact, deliverables list, branding, processing preferences, and portal access are set on a node and apply to its subtree. The six-pit producer sets them once; the ten-pit producer sets them per pit.
• Portal membership is at a node and covers its subtree. The manager over six pits is a member at the parent and sees all six. A pit manager is a member at the pit and sees one. Nothing else is needed for per-project restriction.
• Work orders attach to the node where the work happens and roll up. Appointments, flights, files, and deliverables hang under the work order. A recurring program creates work orders at a node on a schedule, and a campaign can span many nodes.
• History stays with the node. A quarry flown for years under successive contracts is one node with a long list of work orders, so volumes and progress compare across all of them. When a property changes hands, the node moves to a new parent and keeps its history.

Neither app has this shape today. DroneVision has companies with flat projects, and DSP has clients with a site address on every work order. The tree replaces both, and a module that knows its customers usually have one level, as construction does, shows the parent and child as one screen.

Row isolation, done twice on purpose

The primary fence is in code: every database query goes through a data-access layer that requires the acting operator, and a test rule rejects any table access outside it. DroneVision already proved the team can hold that line with its guard helpers. The second fence is row-level security keyed on the operator, switched on with real policies, applied to server queries as well by setting the operator on the connection. The service role is confined to webhooks, the one-time data load, and the job worker. Membership lives in its own table so no policy ever has to look up the users table from inside a users policy, which is the recursion that made DroneVision turn RLS off.

Operators have staff. Their clients have users, or just names on a list. Company nodes have site contacts and deliverable recipients, parents have billing and safety contacts, work orders have a crew. The way to keep this from sprawling is to separate four ideas that most systems mash into one "contact" record. Once they are apart, every case above is a relationship, not a new kind of record.

Contacts without the contact-record burden

The Person record exists for everyone, but creating one is invisible. Every place that asks for a human is a typeahead over the operator's directory, and typing a name and email that is not there creates the Person on the spot. Deduplication is by email, so the same superintendent typed on three job sites is one Person with three assignments. What made contact records cumbersome was mandatory fields and separate screens; here the record is three fields and the screen is optional.

For the genuinely throwaway case, a deliverables list, a bare email address is allowed beside real people. A list is a mix of role keys, specific people, and addresses. Roles resolve at send time, so when the site contact changes the list follows without editing it. An address is promoted to a Person the moment it acquires a second attribute or a role.

Roles without role tables

Roles come from a catalog that tools contribute, the same way permissions do: billing contact, site contact, safety contact, superintendent, project manager, deliverable recipient, grower, applicator, emergency contact. Every assignment is one row: person, role, scope. The scope can be any company node, a work order, or an appointment inside it, and it inherits down the tree. Adding a new kind of contact for a new module is a catalog entry, not a migration.

What each object decides

• Identity and membership decide what someone can see. Client users get membership at a company node, which covers its subtree, in place of the per-project restriction list the Operator Model describes. Operator staff get tool-level permission sets, which is where DSP's eight roles land as presets: pilot, dispatcher, data technician, finance.
• Role assignments decide who is notified, who appears on a report, and whom the field crew calls. They never grant access.
• The Person page shows every role a human holds across every company node and work order, which is what makes cleanup possible: merge two people and their assignments merge.

Two boundaries fixed now

• A Person belongs to one operator's directory. When the same human works with two operators, each holds its own Person record; only the Identity is shared, and only if that human has a login. This keeps one operator's notes private from another and makes erasure tractable: anonymize the Person, keep the assignment history.
• A Person can be affiliated with more than one client company, with a title at each, through a join table rather than a single company field.

All of this is kernel work for stage A: identities and memberships are already in the Operator Model, and Person plus role assignments are two tables and a catalog.

If the platform were built from a blank page with plugins, outbound APIs, and audits in mind, four things would go under the floor before the first feature. All four fit the transition; they only move a few items earlier.

1. The typed API layer

One API defined as typed contracts, with the web interface as its first client and OpenAPI documentation generated from the same definitions. The public API for pushing data out is then the same API with a scoped key instead of a session, not a second system built later. For the DSP port this means handlers land in a framework-independent layer rather than bare framework routes, so porting DSP produces the public API as a by-product. The public surface is versioned by date with a fixed support window, the way Shopify and Salesforce learned to do it, so partners can build against it without fear. Built in stage C, used by every DSP tool from stage D on.

2. The event spine

Every state change writes a domain event to an outbox table inside the same transaction as the change. The worker fans events out to webhooks, plugin triggers, notifications, the audit log, and search. One table and one worker loop give you outbound webhooks, plugin reactivity, a complete audit trail, and replay after a bug. Built in stage A alongside the audit log, because the audit log is what auditors ask for first and it must never be skippable.

3. Manifests, extension points, and the plugin line

A tool ships a manifest declaring its schema namespace, API routes, screens, permissions, events emitted and consumed, jobs, and settings. A module manifest selects tools, sets their facets, and supplies vocabulary and templates. Modules are first-party, trusted, in-process. Plugins are third-party or customer-built, untrusted, out of process.

• Plugin tier one, from stage B: API keys with scopes, OAuth apps for third parties, signed webhooks with retries. This covers most integrations and needs no runtime.
• Plugin tier two, later: a sandboxed runtime for plugin code that reacts to events or adds panels, likely Cloudflare Workers for Platforms so each plugin runs isolated under our dispatch namespace, with iframe extension slots that talk to the page over a small versioned message API.
• Extension points from day one: navigation slots, detail-page panels, event hooks, export formats, map layer sources. First-party tools use them first, so the mechanism is proven before anyone outside touches it.

4. Compliance designed in

SOC 2 and ISO 27001 are mostly organizational controls, and about a third of the evidence is technical. The design makes the technical evidence generate itself.

Order: SOC 2 Type I, then Type II after a monitoring window, then ISO 27001 only if a buyer requires it. The attorney items from the Operator Model, the operator agreement, the partner agreement, and the data processing addendum, belong to the same workstream and start in stage A.

5. Kernel decisions the modules force

Working through the module set surfaced five things that belong under the floor rather than inside any tool.

• Company is a tree. Inspection needs asset hierarchies, Construction needs projects under a contractor, Aggregates need pits under a producer, and one producer puts one manager over six pits while another gives every pit its own billing. One record type that nests, with per-node overrides inherited from the parent, covers all of it without a second record type.
• Work orders and recurring programs are platform records. Business, Inspection, and Aggregates all need "a schedule that creates work orders at a company node." One kernel mechanism, three views of it. The recurring engine is rebuilt as a kernel service in stage D rather than ported as work order code.
• Offline sync is a kernel library. Application records, field notes, and inspection findings are entered where there is no signal. The local-store-and-upsert pattern from txFieldNotes becomes something any field-facing tool declares in its manifest.
• Metering covers storage and delivery, not only processing. A media-only plan has almost no processing cost; its cost is stored bytes and delivered video. The usage table carries those metrics from stage B.
• Assets get a content hash at ingest and a retention hold. Chain of custody and any dispute over a photo need proof a file has not changed and a way to block deletion during a hold. Hashing at upload is nearly free now and impossible to retrofit.

What this changes in the stages

• The outbox and the audit log become stage A prerequisites, beside the migration runner and row-level security.
• The typed API layer is built in stage C before the first DSP tool, so the port produces the public API.
• Manifests, the permission catalog, and the extension points are built in stage C rather than after.
• The company tree, work order programs, the asset hash, and the metering shape are in the stage A schema; offline sync is designed in stage C and shipped with the first field tool.

Everything else on this page stands unchanged. Starting over and transitioning arrive at the same platform, which is the argument for the transition over a clean rewrite.

A heavy service is anything that takes longer than a web request or needs hardware the web tier does not have: photogrammetry, tiling, splat training, transcoding, packaging, thermal detection, point cloud work. We will not know the full list up front, and the architecture should not need to. It needs one contract every service speaks, three compute shapes a service can declare, and a routing rule that lets tools ask for a capability rather than a specific engine.

Designed fresh, with no loyalty to where things run today, the heavy side collapses onto one serverless compute plane. Nothing below is a server anyone patches, and every provider bills by use.

Planning for services we do not know yet

• Capabilities, not engines. Tools request orthomosaic, tiles, splat, transcode, package, detect_thermal, volumes. Services advertise which capabilities they fulfill. A new engine is a new fulfiller, and an operator's bring-your-own key is a routing preference.
• Three compute shapes, declared per service. Warm containers for minutes of CPU, GPU on demand for training and inference, a big container for hours. A service says which it needs; the dispatcher already knows how to run each shape, and all three run on the same plane.
• One contract, spoken over HTTP. Claim with a lease, heartbeat, report progress, complete with a manifest of outputs, or fail with a reason. Inputs and outputs are presigned R2 URLs in the job payload. No service holds database credentials, which is what lets a third-party or a wrapped commercial API participate safely and what keeps the audit boundary clean.
• Adapters for engines we rent. A commercial API such as a hosted photogrammetry or a mapping platform is wrapped as a service that fulfills a capability by calling out, so it looks like every other service to the platform and can be replaced without touching a tool.
• Cost is a field on the job. Every job records its class and seconds, so metering per operator and the margin on each plan fall out of the same table without a separate accounting system.

DSP runs five cron jobs, a dynamic report scheduler held in memory, the recurring work order spawner, and an outreach queue, all inside the web process. None of that has a home in a serverless web tier, and none of it belongs there.

The "Today" column is the migration list. Every service on a droplet becomes a container on Modal, in whichever of the three shapes it needs, which retires the txTiler droplet, the ODM cluster, and Railway. One thing to verify before the photogrammetry move: Modal publishes a full-day timeout and three terabytes of scratch disk, but not its memory ceiling, and the largest flights need tens of gigabytes. Ask for the number; if it is short, the dashed fallback in the map handles only those flights through the same contract.

Two more decisions taken fresh rather than inherited. The API is written on a runtime-agnostic framework, so it runs inside the Vercel deployment today and could move to Cloudflare Workers beside the plugin sandboxes without a rewrite. Events and jobs stay in Postgres rather than a queue product, because auditability and replay matter more here than throughput, and one database is one less system to certify.

Portability: switching providers later

The freedom to move to EC2, S3, or anywhere else comes from three interfaces, not from good intentions. Services and tools touch providers only through the S3 API for files, the jobs API for work, and an auth adapter for identity. A lint rule flags a provider SDK imported anywhere else.

Four rules keep this true. The dispatcher has a provider interface from day one with two implementations. Infrastructure is declared as code, so a second environment is a re-apply, not a rediscovery. Once a year one real job runs end to end on the fallback provider, because a portability claim never exercised is a hope. And the reasons to switch are named in advance: an enterprise buyer that requires AWS, EU data residency, GPU availability, or a scale where owning capacity beats renting it by the second.

The picture that matters is not which app is bigger. It is that the two apps share no identity, no client record, and no project record, so nothing built on either can be sold to a second operator. The fix is one record above both, and every module keyed to it.

These numbers come from reading the code, not from memory. They explain why the plan treats the two apps so differently.

Read the last two rows together. DSP has the product and a front end that survives the move. What does not survive is its server, and that is the part that has to change no matter what.

You asked whether DSP is on the right platform. The server is not, and the honest part is that it would be rewritten under any option below, because adding an operator column and leaving single-writer SQLite touches every one of its inline SQL calls and every synchronous transaction. Once the rewrite is a given, the only question is what to rewrite into.

What makes the rewrite safe is the seam that already exists. The front end never touches the database; it calls one file. That file is the specification.

The specific technical calls inside that recommendation

• Drizzle, not the Supabase client, for DSP domains. Invoice numbering, recurring work order spawning, and the outreach daily cap need real transactions, and a typed schema is the single biggest accuracy lever when agents do the porting.
• Migration files generated from DSP's own table definitions, plus the operator column, with fixed conversion rules for the SQLite habits: date literals, integer booleans, insert-or-ignore, and the two date functions.
• Files go to R2 through the presign and multipart code DroneVision already has.
• Supabase Auth with the Google provider and a per-operator list of allowed email domains replaces the hard-coded txdroneco.com lock.
• Pages port as client components first. Router links change, inline styles stay, the 3,400-line work order detail page moves as one piece and is split afterwards.

What would reopen this decision: a hard commitment to show a multi-operator product within about six weeks. Nothing else in the facts points elsewhere.

The kernel is not built from scratch in an empty repository. It is grown inside DroneVision, because DroneVision is production, multi-company, and closest to the target. Once txDroneCo runs on the operator record, DroneVision is sellable on its own, and the DSP tools land on the same record afterwards. The codebase is restructured into the DroneService Pro monorepo when the first DSP tool arrives, not before.

Contract first, one URL group at a time. The client file that lists the 304 API functions is the specification; each function gets a route handler with the same path, the same request shape, and the same response, checked by the diff. The order below follows the foreign keys.

Made already: the platform is named DroneService Pro, DroneVision is a module inside it that can also be bought alone, operators are the paying tenant, direct companies get a hidden operator record, DroneVision's stack is the platform, DSP is rewritten into it rather than modernized in place, there is no near-term demo deadline. What remains shapes stages B and G.