Technodrive

Transportation and parcel platform

Comment

TechnoDrive — An Operating Platform for Mobility

Inspiration

TechnoDrive began with real operational problems faced by transportation businesses.

Many operators still depend on phone calls, messaging applications, spreadsheets, handwritten records, and disconnected systems to manage customers, drivers, vehicles, trips, parcels, and payments.

This fragmentation creates recurring problems:

  • Slow and inefficient driver assignment.
  • Poor visibility into driver and vehicle availability.
  • Conflicting records between branches and operational teams.
  • Weak parcel custody and handover tracking.
  • Difficult cash and electronic-payment reconciliation.
  • Limited and delayed operational reporting.
  • Heavy dependence on manual work.
  • Difficulty identifying responsibility when an operational failure occurs.

Starting from this reality, we began researching technical solutions inspired by proven international mobility, transportation, logistics, and software-engineering experiences.

Our goal was not to copy an existing platform. We wanted to understand successful technical approaches and adapt them to markets that combine:

  • Individual passenger trips.
  • Shared transportation.
  • Scheduled routes.
  • Intercity services.
  • Parcel delivery.
  • Cash payments.
  • Cash on delivery.
  • Electronic payments.
  • Company-owned fleets.
  • Independent drivers.
  • Multiple branches and transportation operators.

TechnoDrive became our attempt to build a configurable digital operating platform for transportation businesses.

What It Does

TechnoDrive is a multi-tenant mobility and logistics platform.

Each transportation company operates as an independent tenant with its own:

  • Branches.
  • Administrators.
  • Drivers.
  • Vehicles.
  • Customers.
  • Enabled services.
  • Subscription limits.
  • Branding.
  • Operational records.
  • Financial records.

The platform is designed to manage:

  • Customer and driver onboarding.
  • Phone-number and identity verification.
  • Tenant subscriptions and service entitlements.
  • Driver and vehicle eligibility.
  • Trip creation and dispatch.
  • Shared and scheduled transportation.
  • Parcel pickup, custody, tracking, and delivery.
  • Electronic payments and cash collection.
  • Cash-on-delivery settlement.
  • Notifications.
  • Support operations.
  • Monitoring, security, and governance.

The long-term objective is to allow transportation operators to launch and manage digital services without rebuilding every foundational technical component from the beginning.

How We Built It

TechnoDrive is primarily built with Java and Spring Boot using a distributed service architecture.

The platform includes services and capabilities for:

  • API Gateway and service discovery.
  • Authentication and identity.
  • User management.
  • SaaS tenant and subscription management.
  • Trip management.
  • Dispatch.
  • Shared and scheduled transit.
  • Parcel management.
  • Parcel fulfillment, commerce, operations, and resolution.
  • Driver and fleet management.
  • Fleet compliance and tracking.
  • Payments and financial operations.
  • Notifications and communication.
  • KYC and identity verification.
  • Support operations.

The platform uses:

  • Keycloak, OAuth 2.0, OpenID Connect, and JWT for identity and access control.
  • PostgreSQL for service-owned data.
  • PostGIS for locations and spatial queries.
  • Apache Kafka for asynchronous communication.
  • Redis for temporary and operational state.
  • Flyway migrations for controlled database evolution.
  • Transactional Outbox for reliable event publication.
  • Inbox and processed-event records for duplicate protection.
  • Maven and JUnit for building and testing.
  • JaCoCo, Checkstyle, PMD, and SpotBugs for quality validation.

A standardized event envelope contains information such as:

{
  "eventId": "uuid",
  "eventType": "TRIP_COMPLETED",
  "eventVersion": 1,
  "tenantId": "uuid",
  "aggregateId": "uuid",
  "producer": "trip-service",
  "occurredAt": "timestamp",
  "payload": {}
}

Multi-tenancy is enforced across:

  • Authentication and authorization.
  • Database queries.
  • Repository methods.
  • Events.
  • Cache keys.
  • Idempotency records.
  • Logs.
  • Background processing.
  • Administrative operations.

The Payment Service is treated as the authoritative financial source of truth. Trip and Parcel services retain only the contextual payment state required for their operational workflows.

TechnoDrive is also supported by a detailed technical architecture book that documents the platform’s trust boundaries, tenant isolation, service ownership, event-driven reliability, financial truth, operational workflows, and future AI-assisted capabilities.

The architecture book is evidence-bounded: it distinguishes implemented source-level behavior from capabilities that still require runtime, integration, or production-like validation.

How We Used Codex and GPT-5.6

Codex was used as a repository-level engineering agent throughout the project.

It helped us:

  • Inspect a large multi-service codebase.
  • Trace service dependencies and ownership boundaries.
  • Identify incomplete or conflicting implementations.
  • Implement targeted security, persistence, eventing, and domain fixes.
  • Expand behavioral and integration tests.
  • Run Maven quality gates and static-analysis tools.
  • Diagnose build, coverage, configuration, and dependency failures.
  • Identify the first real blocker in failed validation runs.
  • Produce evidence linked to specific commits, source trees, and execution runs.
  • Separate service-specific remediation into reviewable changes.

Codex was particularly valuable when working across:

  • Tenant isolation.
  • Payment idempotency.
  • Database migrations.
  • Outbox and event handling.
  • Driver and fleet eligibility.
  • KYC.
  • SaaS plans and metering.
  • Static analysis.
  • Test coverage.
  • Repository reconciliation.

GPT-5.6 was used for system-level reasoning, architecture review, and project governance.

It helped us:

  • Review the platform vertically by service.
  • Review complete workflows horizontally across services.
  • Define service boundaries and authoritative sources of truth.
  • Identify duplicated ownership and hidden coupling.
  • Design security, financial, data, and operational controls.
  • Evaluate production-readiness claims.
  • Distinguish implemented functionality from unproven runtime assumptions.
  • Review Codex execution reports and determine what was closed, blocked, or still open.
  • Convert findings into architecture decisions, integration matrices, lifecycle models, and production-readiness gates.
  • Prepare the project story and technical presentation.

GPT-5.6 and Codex were used together:

GPT-5.6 provided architectural reasoning, review criteria, and governance, while Codex performed repository-level inspection, implementation, testing, diagnostics, and evidence collection.

Challenges We Ran Into

Hidden Complexity

The project initially appeared to be a relatively simple transportation application.

However, every feature revealed a larger operational workflow.

Assigning a driver requires checking:

  • Identity verification.
  • Driving-licence validity.
  • Vehicle eligibility.
  • Tenant subscription status.
  • Service entitlement.
  • Driver availability.
  • Compliance restrictions.
  • Current assignments.
  • Operational and financial blocking conditions.

Delivering a parcel requires:

  • Pickup confirmation.
  • Custody transfer.
  • Secure scanning.
  • Replay protection.
  • Delivery evidence.
  • Failed-delivery handling.
  • Cash collection.
  • Settlement.
  • Dispute management.
  • Return processing.

Service Ownership

It was difficult to determine which service should own each business fact.

For example:

  • Trip owns trip execution.
  • Payment owns financial truth.
  • Fleet owns driver and vehicle eligibility.
  • SaaS owns tenant, subscription, and entitlement truth.
  • Parcel owns custody and delivery state.
  • Identity infrastructure owns authenticated identity.
  • Notification owns delivery processing, but not the business state that triggered the notification.

Without clear ownership, services can store conflicting versions of the same information.

Multi-Tenant Isolation

A single unsafe database query could expose one tenant’s data to another.

Tenant isolation therefore had to be applied to:

  • Repository methods.
  • Custom queries.
  • Database policies.
  • Events.
  • Caches.
  • Reports.
  • Support operations.
  • Payment callbacks.
  • Scheduled jobs.
  • Internal service calls.

Distributed-System Failures

We had to design for:

  • Duplicate messages.
  • Delayed events.
  • Network failures.
  • Partial success.
  • Out-of-order events.
  • Repeated payment webhooks.
  • Service restarts.
  • Concurrent driver assignment.
  • Consumer failure after partial processing.
  • Provider responses with unknown outcomes.

This required:

  • Retry and backoff.
  • Dead-letter handling.
  • Idempotency.
  • State-transition validation.
  • Transactional event publication.
  • Reconciliation.
  • Explicit failure and recovery behavior.

Payments and Cash

Payments were significantly more complex than expected.

The platform must account for:

  • Duplicate callback detection.
  • Delayed payment confirmation.
  • Webhook authentication.
  • Refunds.
  • Electronic payments.
  • Cash payments.
  • Cash on delivery.
  • Driver commissions.
  • Operator settlement.
  • Platform fees.
  • Reconciliation.
  • Unknown payment outcomes.
  • Prevention of duplicate financial effects.

Parcel Custody

Tracking a parcel’s location does not prove who is responsible for it.

We therefore separated:

  • Location tracking.
  • Parcel status.
  • Custody holder.
  • Handover records.
  • Scan history.
  • Delivery evidence.
  • Cash custody.
  • Dispute status.

Driver Availability and Dispatch

Driver availability could not be represented by a single online flag.

A driver may appear online while remaining ineligible because of:

  • Expired documents.
  • An ineligible vehicle.
  • Tenant suspension.
  • Compliance restrictions.
  • An existing assignment.
  • An invalid operational region.
  • A financial restriction.

Dispatch also required concurrency controls to prevent the same driver from being assigned to multiple incompatible requests.

Development Infrastructure and Lack of Support

One of the largest practical obstacles was the limited development infrastructure available to the project.

The work was affected by:

  • Limited local computing resources.
  • Slow and unstable internet connectivity.
  • Dependency download failures.
  • Difficulty running many services simultaneously.
  • Limited access to hosted testing environments.
  • Lack of a dedicated engineering team.
  • Limited technical, financial, and operational support.
  • The need to perform architecture, development, testing, documentation, and review with minimal resources.

These constraints increased development time and made repeatable integration and end-to-end testing more difficult.

Repository and Evidence Management

The project accumulated a large number of changes across many services and branches.

This created challenges around:

  • Determining the authoritative baseline.
  • Separating previous work from new changes.
  • Preventing unrelated changes from entering the same validation gate.
  • Binding test evidence to the correct commit.
  • Avoiding stale reports.
  • Reproducing results from a clean clone.

We addressed this by introducing:

  • Controlled execution envelopes.
  • Atomic service-owned changes.
  • Commit and tree fingerprints.
  • Reproducible evidence directories.
  • Source-state checks before and after validation.
  • Explicit production-readiness gates.

Production Readiness

A successful build does not prove production readiness.

The platform must still prove:

  • Cross-tenant isolation.
  • Complete trip, transit, and parcel lifecycles.
  • Real notification delivery.
  • Payment reconciliation.
  • Provider failure handling.
  • Backup and restore.
  • Monitoring and alerts.
  • Hosted continuous integration.
  • Preproduction behavior.
  • Failure recovery.
  • Clean-clone reproducibility.
  • End-to-end frontend and mobile integration.

The current release remains under active development and production-readiness validation.

Production Verdict: NO-GO

The next controlled milestone is:

Local Production Parity GO

This milestone means proving that the same governed source, migrations, business logic, security behavior, and release artifacts can later be promoted without modifying application code or rebuilding different binaries for each environment.

Accomplishments We Are Proud Of

We are proud of transforming the original idea from a basic transportation application into a coherent operating platform.

Important accomplishments include:

  • Establishing clear service and data ownership.
  • Designing tenant-aware identity and security.
  • Making Payment the authoritative financial source of truth.
  • Introducing standardized event envelopes.
  • Implementing Outbox, Inbox, retry, dead-letter, and idempotency patterns.
  • Building a deeper parcel custody and delivery model.
  • Separating individual trips from scheduled transportation.
  • Treating driver availability as a composite eligibility decision.
  • Designing explicit production-readiness gates.
  • Producing extensive architecture, integration, and lifecycle documentation.
  • Improving behavioral tests and static-analysis quality across several services.
  • Maintaining an honest readiness assessment rather than declaring the platform complete too early.

What We Learned

We learned that:

  • Microservices are useful only when service boundaries are clear.
  • A service must know both what it owns and what it must not own.
  • Distributed systems must expect failure, duplication, and delay.
  • Multi-tenancy must be enforced throughout the entire platform.
  • Payment is a financial domain, not only an API integration.
  • Parcel tracking is not the same as parcel custody.
  • Driver availability is a composite business decision.
  • Operational metrics and commercial usage metering are different systems.
  • Documentation must remain aligned with source code and runtime evidence.
  • A clean repository and reproducible evidence are part of engineering quality.
  • Local success is not production proof.
  • Limited infrastructure can be partially addressed through disciplined engineering, but it significantly affects speed and validation.
  • An honest NO-GO decision can protect a project from a premature and risky launch.

What’s Next for TechnoDrive

The next phase will focus on:

  • Completing tenant-isolation proofs.
  • Closing cross-service integration contracts.
  • Completing payment, settlement, and reconciliation workflows.
  • Proving complete trip, transit, and parcel lifecycles.
  • Completing customer and driver onboarding.
  • Strengthening dispatch and concurrency controls.
  • Completing frontend and mobile integration.
  • Establishing hosted CI and preproduction environments.
  • Adding monitoring, alerting, backup, restore, and rollback validation.
  • Completing clean-clone and immutable-artifact validation.
  • Launching a controlled operational pilot.

After the platform begins real operation and collects sufficient high-quality data, we plan to introduce model-driven and AI-assisted services.

These services will be introduced only after obtaining reliable, representative, anonymized, and governed operational data.

Route Optimization

Machine-learning and mathematical optimization models may help:

  • Select more efficient routes.
  • Reduce travel time.
  • Reduce fuel consumption.
  • Improve multi-stop parcel delivery.
  • Adjust routes using traffic patterns and operational history.

A simplified routing objective may be expressed as:

$$ \min \left( \alpha \cdot \mathrm{Distance} + \beta \cdot \mathrm{TravelTime} + \gamma \cdot \mathrm{OperatingCost} \right) $$

The coefficients (\alpha), (\beta), and (\gamma) represent configurable business priorities.

Demand Forecasting

Demand-forecasting models may estimate future demand by:

  • Region.
  • Time of day.
  • Day of the week.
  • Route.
  • Service type.
  • Seasonal pattern.
  • Historical operational events.

A simplified forecasting model can be represented as:

$$

\hat{D}_{r,t}

f\left(H_{r,t}, W_t, S_t, E_t\right) $$

where:

  • (H_{r,t}) represents historical demand in region (r) at time (t).
  • (W_t) represents weather or environmental factors.
  • (S_t) represents seasonal patterns.
  • (E_t) represents events or exceptional conditions.

Intelligent Fleet Positioning

Demand predictions may help recommend where drivers and vehicles should be positioned before requests arrive.

This could reduce:

  • Passenger waiting time.
  • Empty vehicle movement.
  • Fuel consumption.
  • Dispatch latency.
  • Regional supply shortages.

Improved Dispatch

Operational data may later be used to improve driver selection using:

  • Estimated arrival time.
  • Driver reliability.
  • Acceptance probability.
  • Demand distribution.
  • Vehicle suitability.
  • Operational cost.
  • Compliance and eligibility.
  • Fair workload distribution.

We do not plan to train these models using unsupported assumptions alone.

The models will be introduced only after operational deployment produces sufficient data and after privacy, governance, fairness, quality, and monitoring requirements are defined.

Final Vision

TechnoDrive aims to become an Operating System for Mobility: a governed, auditable, multi-tenant, and scalable platform connecting:

  • Passengers.
  • Drivers.
  • Vehicles.
  • Parcels.
  • Payments.
  • Transportation operators.
  • Support teams.
  • Financial teams.
  • Operational teams.

The final objective is to allow transportation businesses to launch and operate digital services without rebuilding identity, fleet management, dispatch, payments, parcel delivery, notifications, support, monitoring, and governance from zero.

We are proud not only of what we have built, but also of the problems we identified, the architectural decisions we corrected, and the discipline required to acknowledge what still needs to be completed.

Built With

  • apache-kafka
  • codex
  • eureka
  • flyway
  • gpt-5.6
  • jacoco
  • java
  • junit-5
  • jwt
  • keycloak
  • maven
  • microservices
  • multi-tenant-saas
  • oauth-2.0
  • openapi
  • openid-connect
  • postgis
  • postgresql
  • redis
  • rest-api
  • spring-boot
  • spring-cloud
  • spring-cloud-gateway
  • spring-data-jpa
  • spring-security
Share this project:

Updates