The Argument, Up Front.
A marketplace that tracks a moving asset has already built a general dispatch engine and named it after its first product. That is the argument of this whitepaper: a dispatch platform architecture that knows where every party is, knows who is available, and can route a request to the nearest one who can serve it holds a capability that does not care what the job is, and most operators evaluate a second product as though it were a second build. The Town Connect Network implementation is the evidence: five roadside emergency services running on the same GPS and job-routing infrastructure that moves the shipments, with no parallel system built.
The observation is narrow and checkable. Strip a logistics marketplace to its load-bearing parts and four of them are job-agnostic: a live location layer, an availability model, a matching and routing function, and a status surface. Job type is a parameter passed to that engine rather than a property of it. What differs between moving a vehicle and jump-starting one is the job schema, the pricing and the provider pool, all of which sit above the engine.
Four patterns explain why this goes unnoticed, and this whitepaper rejects all four: the parallel system, the exit to solve, uniform sampling, and interface-enforced permissions in a marketplace.
Five principles resolve it. Job type is a parameter rather than a structure. Incidents that arise during a job are resolved inside the product running it. Sampling fidelity follows information value rather than a fixed schedule. In a marketplace the permission boundary is peer-to-peer, so it belongs at the API. And structural role separation is settled in the data model before substantial code exists.
NewAgeSysIT built this architecture for Town Connect Network, a Florida-based vehicle transport marketplace, under the strategic advisory guidance of Giovanni Livia, as a dispatch and logistics platform rather than a tracking feature with a marketplace attached.
The argument is sector-general. It holds for courier, field service, on-demand and roadside operations, for any marketplace that routes work to a party who moves. Vehicle transport is the worked example, not the subject.
Location, Availability, Matching, and Nothing Job-Specific.
Strip a logistics marketplace down to its load-bearing parts and almost nothing that remains is about logistics. What remains is a system that knows where things are, knows who is available, and can match a request to the nearest party who can serve it, and none of those three capabilities cares what the job is.
Job type A
Vehicle shipment
Job type B
Roadside assistance
Configuration layer, job-specific
The dispatch engine, job-agnostic
Live location layer
Tracks moving parties
Availability model
Knows who can take work
Matching and routing
Selects the nearest or best-fit party
Status surface
Lets a requester watch an assignment approach and complete
The four primitives. A live location layer that tracks moving parties. An availability model that knows who can take work. A matching and routing function that selects the nearest or best-fit party. And a status surface that lets a requester watch an assignment approach and complete. Between them they constitute the engine, and not one of them contains a fact about freight.
The observation the paper turns on. Job type is a parameter to that engine, not a property of it. What differs between moving a vehicle and jump-starting one is the job schema, the pricing and the provider pool. All three sit above the engine. None sits inside it.
Why teams do not notice. The engine is built in service of the primary product and is named after it. Nobody sets out to build a dispatch engine. They build the shipment tracking system, and the name conceals the generality so completely that the second product is invisible to the people who already own its infrastructure.
The asymmetry that makes this worth writing about. The marginal cost of a second job type on an existing engine is a fraction of the cost of the first. The marginal revenue is not correspondingly smaller. Operators routinely evaluate a second product as though it were a second build, which prices it out of the roadmap on a comparison that does not hold.
For the freight case specifically, the second job type is not hypothetical. The ATA Technology and Maintenance Council ran a quarterly Vertical Benchmarking Program with FleetNet America across truckload, less-than-truckload and tank fleets until the programme closed at the start of 2023. In the first quarter of 2021 participating fleets averaged 29,506 miles between unscheduled roadside repairs, with truckload carriers at 21,856 miles and tank fleets at 17,420. A truck covering a hundred thousand miles a year on those figures meets a roadside event several times over. Breakdowns are not an edge case in road freight. They are a recurring event inside the job the platform is already tracking.
The scope boundary, stated honestly, because this is how the argument would be misused. It holds only where the second job type shares the same primitives. An adjacent product needing different ones, a scheduling product with no location component for instance, gets no discount from this architecture, and claiming otherwise turns a real structural insight into a sales line.
The question for any operator running a live-location marketplace is therefore not whether the engine could route something else. It is which something else is worth routing. The next two sections deal with what has to be true architecturally for that answer to be cheap.
Source
- ATA Technology & Maintenance Council and FleetNet America. Vertical Benchmarking Program, a quarterly benchmark of unscheduled roadside repairs across truckload, less-than-truckload and tank fleets. The programme closed on 1 January 2023, so these are historical figures. Q1 2021: 29,506 miles between unscheduled roadside repairs across all participating fleets, truckload 21,856, tank 17,420.
Got Problems? Let Us Help You With the Right Solution
Four Reasonable Decisions That Cost You a Product.
Four patterns explain why most marketplaces never notice the second product sitting inside their own infrastructure, and why the ones that do often build it twice. Each was a sensible decision when it was made, which is why it is worth examining.
The Parallel System
The adjacent product is recognised as an opportunity and built as its own system, with its own location handling, provider directory and matching logic, usually by a separate team on a separate timeline.
Two systems now track the same vehicles and answer the same question differently. Position data diverges, providers exist in two directories, and a user in one product cannot be seen from the other, which is precisely the moment a cross-product experience would have been worth something.
The cause is organisational rather than technical, and naming it correctly matters. The second product is justified with its own business case, which means its own budget, which means its own build. The architecture follows the funding structure rather than the problem structure, and by the time anyone notices, two teams each own half a dispatch engine and neither will give theirs up. This is the failure the thesis answers most directly, and it is why a platform consolidation conversation is usually a governance conversation first.
The Exit to Solve
An incident the platform considers out of scope, a breakdown, a failed delivery, a dispute, sends the user out of the product to resolve it by telephone or through a third party.
The operator loses two things simultaneously, both at the worst possible moment: visibility of the job for the duration of the incident, and the customer relationship at the point the customer most needs someone. The job goes dark in the system of record while the person inside it is having the hardest hour of the week.
The reframe is worth stating plainly. An incident during a job is not out of scope. It is the moment the platform's core capability, knowing where the party is and who could reach them, has its highest value, and it is the moment most platforms choose not to use it. Handling incidents in-product costs less to build than it looks, because the routing and matching engine is already there.
Uniform Sampling
Fixed-interval location polling, chosen once and applied to every tracked party in every state.
It collides with a physical constraint. Continuous high-frequency polling drains battery and bandwidth on a device the operator does not own and cannot recharge. On a long haul that is not a tuning inconvenience. It is a reason drivers turn the feature off, and a tracking feature that is switched off is worth less than none, because the operator now believes they have visibility they do not have.
The principle underneath is that sampling fidelity should follow information value. A stationary vehicle at a dock generates almost no new information per sample. A moving one generates a great deal. Spending the same rate on both wastes the budget where it buys nothing and constrains it where it matters. Uniform is the default because it is the easiest thing to specify, not because it is correct.
Interface-Enforced Permissions in a Marketplace
Role scope implemented by hiding or disabling interface elements, with the backend trusting that requests only ever arrive through the application.
The threat model makes this different from the usual version of this argument. In a multi-party marketplace the risk is not principally external. It is peer-to-peer. A carrier reaching another carrier's jobs, or a shipper reaching a fleet's driver positions, is a competitor obtaining commercially sensitive data through a system that was supposed to mediate between them.
That raises the stakes above ordinary access control. The platform's value proposition is that rival parties can transact through it safely, so a permission failure here is not only a data incident. It removes the reason the marketplace exists. The boundary belongs at the API, which is the first thing any serious security review of a marketplace should test.
| Pattern | Why it gets chosen | Where it breaks | What it costs |
|---|---|---|---|
| The parallel system | The second product has its own business case and budget | Two directories, two position records, no cross-product view | A dispatch engine built twice |
| The exit to solve | The incident looks like someone else's problem | The job goes dark at its highest-stakes moment | Visibility and the relationship, together |
| Uniform sampling | Fixed intervals are the easiest thing to specify | Battery and bandwidth on hardware you do not own | A tracking feature users disable |
| Interface permissions | The client is the only caller anyone tested | Scope evaporates when the API is called directly | The reason the marketplace exists |
Job Type Is Data. Everything Else Is Shared.
A dispatch platform architecture earns its second product by treating the job type as configuration rather than as structure: one engine for location, availability, matching and status, with everything job-specific held above it in a layer thin enough to add another entry to.
What follows is product-agnostic. An architect in courier, field service, on-demand or roadside could implement it without ever seeing Town Connect. The evidence arrives next.
Architecture Diagram
One Dispatch Engine, and Where Each Principle Applies
Vehicle shipment
Roadside assistance
The next entry
The Dispatch Engine
Live location layer
Tracks moving parties
Principle 3
Sampling follows information value
Availability model
Knows who can take work
Matching and routing
Selects the nearest or best-fit party
Principle 1
Capability read off the job
Status surface
Lets a requester watch an assignment approach and complete
Incidents routed as linked jobs
Same primitives, a different provider pool, the parent job's status stays live
Structural role separation
Settled in the data model before substantial code exists
Job Type Is a Parameter, Not a Structure
The engine routes a request from a requester to the nearest capable provider and reports status. What is being requested is data passed to it, not a branch inside it.
Implementing this requires three things: a job schema that is extensible rather than fixed, a provider model where capability is an attribute rather than a type, and matching logic that reads capability requirements off the job instead of hard-coding them. The third is the one that quietly gets skipped, because hard-coded matching is easier to reason about when there is only ever one kind of job.
Describe the shape of the saving rather than inventing a number for it. A second job type becomes a schema entry, a provider pool and a pricing rule. The first job type required the entire location, availability, matching and status stack. Those are not the same order of work, and a roadmap that prices them as though they were will never authorise the second one.
Now the uncomfortable part, and it is the part worth keeping. Building the first product this way costs slightly more, and the saving arrives later, in a quarter nobody is currently planning for. Teams that optimise the first build hardest are the ones that foreclose the second, and they do it without a decision ever being taken. Nobody writes down "we are giving up the adjacent product." They write down "we shipped on time."
Keep the Incident Inside the Platform
When something goes wrong during a job, the resolution belongs in the product that was running the job.
Implementing this means modelling an incident as a job the engine can route: the same primitives, a different provider pool, linked to the original job so the parent's status reflects the incident rather than going silent. That link is the part that does the work. Without it you have a second product that happens to live in the same application, which is not the same thing at all.
What it buys, in the order that persuades: visibility of the original job is preserved through the incident, so the operator and the customer waiting at the other end both still know what is happening. The relationship stays inside the product at its highest-stakes moment. And a new provider category, with its own economics, becomes addressable through infrastructure that is already paid for.
Make the boundary explicit so the principle is usable rather than absolute. Not every incident belongs in the product. The test is whether the platform's existing primitives can resolve it. If the answer needs location, availability and routing, it belongs inside. If it needs a lawyer, it does not, and pulling it in anyway builds a parallel system wearing your product's name.
Spend Fidelity Where It Changes the Answer
Sampling rate should follow information value, not a fixed schedule.
Implementing this requires a signal that indicates state, motion being the obvious one, and polling intervals that vary against it, with the transition handled so the map does not visibly lag when a stationary party starts moving again. That transition is where naive implementations fail, and it is what a user notices.
What it buys is accuracy where accuracy changes a decision and near-zero cost where it does not. On a device the operator does not own, this is the difference between a feature users keep enabled and one they disable, which is a product outcome rather than an infrastructure one.
Generalise this deliberately, because it is the most portable idea in the document. The same reasoning governs any refresh, poll or telemetry interval where the observed thing has idle states. It is an engineering principle rather than a GPS trick, and it applies as well to a cloud-hosted data pipeline as it does to a phone in a truck.
In a Marketplace, the Permission Boundary Is Peer-to-Peer
Enforce role scope at the API, because in a multi-party marketplace the party you are protecting each user from is another user of the same platform.
Implementing this means scope as a backend property evaluated per request, plus encryption on the flows carrying commercially sensitive data: positions, job records, verification codes.
What it buys beyond compliance is the marketplace's core promise. Rival parties transact through the platform because they believe it keeps them apart, and that belief is only as good as the weakest permission check in it.
Settle Structural Role Separation Before the Build
Where several parties act on one shared record and want genuinely different things from it, the separation is structural rather than presentational, and it has to be settled in the data model before substantial code exists.
The cost of getting it wrong is one sentence long: retrofitting means rebuilding the data layer, not redesigning screens.
What it buys is that every later role, including the provider pool a second job type introduces, is an addition rather than an exception.
At a Glance
The Five Principles
-
01
Job type is a parameter, not a structure.
Makes sharing valuable
-
02
Keep the incident inside the platform.
Makes sharing valuable
-
03
Spend fidelity where it changes the answer.
Makes it affordable to run
-
04
In a marketplace, the permission boundary is peer-to-peer.
Makes it safe to share
-
05
Settle structural role separation before the build.
Makes it safe to share
Giovanni Livia, Independent AI & Software Solutions Consultant | Implementation by NewAgeSysIT
Principles 4 and 5 are what make an engine safe to share. Principles 1 and 2 are what make sharing it valuable. Principle 3 is what makes it affordable to run. An operator with 4 and 5 but not 1 has a well-built single product. An operator with 1 but not 4 has a liability.
Five Emergency Services on the Shipment Platform's Own Infrastructure.
NewAgeSysIT implemented this architecture for Town Connect Network, a Florida-based marketplace connecting parties who need vehicles moved with the carriers who move them, plus a dispatch layer for fleet operators managing drivers across an operation, under the strategic advisory guidance of Giovanni Livia.
Three user types act on one shipment record. A shipper needs vehicles moved. A carrier moves them. A company oversees multiple carriers and assigns jobs to the drivers best suited to them. Live map tracking runs from pickup through to delivery, and both applications run from a single React Native codebase. The full client narrative and delivery detail are published in the Town Connect case study.
Principle 1 in practice, and the core evidence. Five emergency services, tow, tire change, jump start, lockout and fuel delivery, are built directly into the platform and dispatched to the nearest provider through the same GPS and job-routing infrastructure that moves the shipments. No parallel system was built. A driver requesting help watches the provider approach on the same map surface a shipper uses to watch a load, because it is the same map surface. What the second product required was a job schema, a provider pool and a pricing rule. What it did not require was a location layer, an availability model, a matching function or a status surface, because all four already existed and none of them had an opinion about freight.
Principle 2 in practice. The reasoning behind the module is worth reporting because it is the reframe stated by an operator rather than by a consultant: a platform that already tracks a vehicle in real time has everything it needs to dispatch help to that vehicle, so the breakdown belongs inside the product rather than outside it. That is failure mode 2 identified from the inside, by someone who was losing the job and the relationship every time a driver hung up and called a tow company.
Principle 3 in practice. Adaptive GPS intervals, polling frequently while the carrier is moving and backing off while stationary, so tracking stays accurate on the road and costs almost nothing while a truck sits at a dock waiting to load.
Principles 4 and 5 in practice. Role-based access control is enforced at the API rather than the interface, so a carrier cannot reach another carrier's jobs regardless of what the client requests, with end-to-end encryption on shipment records, live positions and delivery verification codes. The three-role information architecture was settled before substantial code was written, which is why the roadside provider pool was an addition rather than an exception.
Infrastructure, compressed. A modular NestJS backend on Node.js, MongoDB for flexible records alongside MySQL on Amazon RDS for transactional and pricing data, Redis in front, running on AWS and provisioned deliberately beyond the launch user count. Both applications are live on the App Store and Google Play. The case study carries the full stack table and this document does not reproduce it.
Full delivery detail, the complete technology stack and the client narrative are published in the Town Connect case study. This whitepaper borrows the evidence. The case study owns the story.
Client Story
Read the full Town Connect case study
Delivery detail, the complete technology stack and the client narrative.
A Structural Result, Stated Without Metrics.
This implementation produced no published performance metrics, so what follows is structural evidence rather than measured outcome, which is the right kind of evidence for the claim being made, because the claim is about what an architecture makes possible rather than about how fast it runs.
| Evidence | Before | After | Principle tested |
|---|---|---|---|
| Second product cost | A second dispatch product implies a second build: location, availability, matching, status, again | Five emergency services on the existing engine, no parallel system | Principle 1 |
| Incident handling | Driver exits the platform to find help; operator loses shipment visibility and the relationship at once | Five services dispatched in-app to the nearest provider, tracked on the same surface | Principle 2 |
| Tracking cost on device | Fixed-interval polling drains battery and bandwidth across a long haul | Adaptive intervals tied to vehicle motion | Principle 3 |
| Permission boundary | Role scope enforced in the interface, backend trusting the client | RBAC enforced at API level with encryption on sensitive flows | Principle 4 |
| Distribution | Pre-launch | Live on the App Store and Google Play from one React Native codebase | Not a principle, but it establishes that the above describes a shipped system rather than a design |
Second product cost
Before
A second build
After
No parallel system
Incident handling
Before
Driver exits the platform
After
Dispatched in-app
Tracking cost on device
Before
Fixed-interval polling
After
Adaptive intervals
Permission boundary
Before
Enforced in the interface
After
Enforced at the API
The first row is the claim and the rest support it. A second dispatch product exists, and the infrastructure underneath it does not duplicate the first. In a category where the conventional answer to a breakdown is to send the driver out of the application, the second product was cheap enough to ship inside the first. That is a structural result, and structural results are the correct evidence for architectural claims, because an architecture is a statement about what will be possible later rather than about what performs well today.
The remaining rows each test a principle in a way a metric would not improve on. Adaptive intervals either exist in the polling logic or they do not. Role scope either holds when the API is called directly or it does not. These are binary architectural facts, and a percentage attached to either would be decoration rather than evidence.
Now state plainly what this does not support, without softening it. There is no measurement of adoption, no roadside request volume, no figure for what the second product earns, and no measure of what it cost to build relative to the first. The structural claim is evidenced. The commercial claim is not, and this document does not make it. A reader evaluating whether to fund a second product on their own engine should take this as proof that the move is architecturally available, not as proof that it pays.
Two numbers would close that gap, and naming them doubles as the ask. Roadside requests served, and roadside as a share of total platform activity, would convert this section from a structural argument into a demonstrated one. Engineering time for the roadside module set against engineering time for the shipment product would evidence the central claim directly, and it is a figure delivery can supply without asking the client at all.
The boundary condition is the same one Section 02 set out and it is worth repeating here, because this is where a reader decides whether the paper applies to them. This pattern earns its cost where the second job type shares the first's primitives: location, availability, nearest-party matching. Where it does not, the engine confers no advantage and the second product is a genuine second build.
Six Decisions Made Before Anyone Mentions a Second Product.
Six decisions determine whether a marketplace ends up with one product or two. Five of them are made during the first build, usually without anyone realising a second product is at stake.
| # | Decision | What to weigh |
|---|---|---|
| 1 | Is job type data or structure | Extensible schema and capability-as-attribute, or job-specific branches throughout the matching logic |
| 2 | Which incidents come inside | Whether your existing primitives can resolve it |
| 3 | What drives the sampling interval | Motion, milestone proximity, time-in-state, job value, or nothing |
| 4 | Where the permission boundary sits | API or interface, and who the other party actually is |
| 5 | One codebase or two | Concentrated platform risk against per-platform native control |
| 6 | Provisioning ahead of demand | Capacity nobody is using, against re-engineering you cannot schedule |
1. Is job type data or structure.
An extensible job schema and capability-as-attribute cost more in the first build and are close to impossible to retrofit, because by then the matching logic carries job-specific branches throughout and every one of them has to be found. This is the decision that determines whether a second product is a quarter's work or a year's, and deferring it does not leave the choice open. It closes it quietly, in favour of one product.
2. Which incidents come inside.
The test is whether your existing primitives can resolve it. Location, availability and routing can resolve a breakdown. They cannot resolve a payment dispute. Pulling in an incident your engine cannot serve builds a parallel system wearing your product's name, which is failure mode 1 arrived at from the opposite direction and just as expensive. The deferral cost here is unusual in that it is mostly opportunity rather than rework: every month the incident stays outside is a month of job visibility the operator never had and a provider relationship someone else owns.
3. What drives the sampling interval?
Motion is the obvious signal and rarely the only one. Proximity to a milestone, time-in-state and job value all change how much a sample is worth. Picking one signal is fine. Picking none and defaulting to fixed intervals is the failure, and the cost of deferring shows up as a feature users have already switched off by the time anyone looks at the telemetry.
4. Where the permission boundary sits.
API or interface. In a two-party product this is ordinary access control. In a marketplace where the other party is a competitor it is the reason customers are willing to use the platform at all, and the cost of getting it wrong is categorically different: not a remediation exercise but a reason to leave.
5. One codebase or two.
One codebase concentrates platform risk and halves the delivery surface. Two gives per-platform control that genuinely matters for deeply native experiences, heavy background processing, complex hardware access. For a product whose users arrive on whatever device they already carry, the calculus usually favours one, but this is a real trade-off rather than a foregone conclusion, and anyone who tells you cross-platform is always right has not built the exception.
6. Provisioning ahead of demand.
Infrastructure provisioned beyond launch volume costs money for capacity nobody is using yet. It buys the ability to onboard a cohort, or launch a second product, without foundational re-engineering. Whether that is prudent or wasteful depends entirely on whether the second product actually arrives, and this one is genuinely wasteful if it never does. A cloud architecture review is the cheapest way to keep the option without paying full price for it.
Two of these six have legitimate answers in either direction. Decision 5 has a real two-codebase case for deeply native products, and Decision 6 is money burned if the roadmap never widens. Saying so is what should make the other four credible. If you want a cost frame before settling any of them, the app development cost estimator gives a working range.
Speak With Our Consultant
Partners
Pressure-test your architecture before you commit to a data model. Work directly with Giovanni and Bibin to validate your technology direction, align the platform with business goals, and make confident decisions that reduce risk and accelerate outcomes.
Request an Architecture Consultation
Five Insights From the Town Connect Build, Each Independently Quotable.
A platform that already knows where every party is, and already routes a request to the nearest one who can serve it, has built a general dispatch engine and named it after its first product. Town Connect's five roadside services run on the same GPS and routing infrastructure that moves its shipments, requiring a job schema, a provider pool and a pricing rule rather than a second build.
When a user leaves your product to solve a problem that arose inside it, you lose two things at the worst possible moment: visibility of the job, and the relationship with the person having the problem. An incident during a job is not out of scope, it is when your core capability is worth the most and when most platforms decline to use it.
Uniform sampling is the wrong default wherever the observed thing has idle states. Polling fidelity should follow information value, because on hardware you do not own the real choice is not between accurate and cheap but between a feature users keep switched on and one they disable.
In a multi-party marketplace the party each user needs protecting from is another user, which makes role scope a commercial guarantee rather than a compliance control. A carrier reaching a rival's job board is not only a data incident. It removes the reason the marketplace exists, which is why the boundary belongs at the API.
The decisions that determine whether a second product is cheap are made during the first one, before anyone is thinking about a second. Treating job type as data rather than structure costs slightly more up front and is close to impossible to retrofit, so the teams that optimise the first product hardest are often the ones that quietly foreclose the second.
From Architecture to Implementation.
Delivery Partner
NewAgeSysIT is a custom software development and AI solutions company in Princeton, NJ, specialising in multi-party marketplaces, dispatch and routing platforms, and full-cycle platform development across mobile, web and cloud.
Founded by Johny John, NewAgeSysIT has delivered software across logistics, automotive, healthcare, real estate, fintech and e-commerce. Recent work is published in the client portfolio.
The company works closely with Giovanni Livia, Independent AI & Software Solutions Consultant, strategic advisor, who helps business leaders scope and sequence platform initiatives before connecting them with NewAgeSysIT for implementation.
Already Tracking a Moving Asset?
If you already run a platform that tracks a moving asset, the most valuable architecture conversation available to you is which second product your existing infrastructure could already serve. Request an architecture consultation with Giovanni Livia to find out what you have already built.
Read the full implementation narrative in the Town Connect case study.
newagesysit.com | [email protected] | 1-609-331-9194 | 4390 US-1, Suite 110, Princeton, NJ 08540