From Concept to Commercialization: Building and Scaling a B2B Mobility Platform

A case study on product development, cloud architecture, fundraising, organizational growth, and the difficult work of turning an idea into an operating business.

Some products begin with a new technology.

TecleTaxi Corporativo began with a gap.

Companies needed a better way to manage employee transportation, service providers, authorized rides, payments, reporting, and operational control.

Consumer mobility applications were becoming visible, but corporate transportation involved a different set of requirements.

A company did not simply need to request a vehicle. It needed to know:

who was authorized;
which department or cost center should be charged;
whether the trip complied with policy;
how payment would be processed;
which records were required for reconciliation;
how the service would be monitored;
who would respond when something went wrong;
how transportation providers could be coordinated.

This was the context in which TecleTaxi Corporativo was conceived.

The goal was to create a B2B mobility platform combining transportation, payment, corporate controls, and operational visibility.

Building the software was difficult.

Building the company around it was harder.

Identifying the Real Product

The first version of an idea is usually expressed through features:

ride requests;
driver and vehicle location;
authentication;
corporate accounts;
payment processing;
administration;
reporting;
operational support.

A feature list does not define a product.

The real product was the operating model connecting employees, corporate customers, transportation providers, payments, and support.

That distinction mattered.

A consumer mobility application can optimize primarily for convenience and transaction volume. A corporate platform must also optimize for control, accountability, predictable billing, permissions, reporting, and contractual obligations.

The buyer, user, operator, and payer may all be different people.

That changes almost every design decision.

The Problem We Were Trying to Solve

Corporate transportation was often managed through phone calls, spreadsheets, paper vouchers, invoices, local suppliers, and manual reconciliation.

This created:

limited usage visibility;
inconsistent authorization;
delayed reconciliation;
difficult contract management;
weak auditability;
dependency on individuals;
limited planning data;
poor incident experience.

The opportunity was not simply to digitize ride requests.

It was to manage mobility as an operational capability.

The platform needed to serve:

corporate administrators;
operational teams;
finance;
transportation providers;
drivers;
employees;
support teams;
commercial stakeholders.

Every group had different priorities.

The platform needed to reconcile them.

From Concept to a Commercial Product

The early phase combined discovery, customer conversations, technical experimentation, and commercial validation.

We needed to determine whether companies would pay for the service and which problems were important enough to change existing behavior.

Some requirements appeared obvious but became more complex in real use.

A corporate ride was not always associated with one employee. It might involve a visitor, shift, project, incident, or service provider.

Authorization could depend on:

time;
role;
department;
location;
cost center;
contract;
vehicle type;
approval rules.

Payments involved more than charging a card.

The platform needed to connect the operational event—the completed journey—to financial records, agreements, pricing, and reconciliation.

Identity, payment, mobility, and reporting were therefore not isolated features.

They were parts of the same business transaction.

Building the Architecture

TecleTaxi was designed as a cloud-based platform on AWS.

It needed to support:

web and mobile experiences;
corporate administration;
driver and provider interactions;
geolocation;
authentication;
payments;
external integrations;
operational monitoring;
reporting;
customer support.

At the time, microservices were increasingly popular. Adopting a highly distributed architecture too early would have introduced operational and organizational costs the company was not prepared to absorb.

We chose a modular approach.

Capabilities were separated around areas such as:

identity;
corporate accounts;
mobility operations;
payments;
geolocation;
notifications;
reporting;
administration.

This preserved clear boundaries without requiring a large number of independently deployed services from the beginning.

The decision reflected a principle:

Architecture should match the organization's current capability while preserving reasonable options for future growth.

A fashionable architecture would not help if the team could not operate it reliably.

Geolocation and Operational State

Location mattered, but geolocation alone was not the product.

The platform needed to combine location events with operational state:

Was the ride accepted?
Was the driver approaching?
Had the passenger boarded?
Was the journey in progress?
Had it completed?
Had an exception occurred?
Was the transaction ready for financial processing?

Location data could be delayed, incomplete, or inaccurate. Connectivity varied. Drivers and passengers could act outside the expected sequence.

The system needed to tolerate imperfect real-world behavior rather than assume every event would arrive correctly and in order.

The physical world does not behave like a controlled software test.

Payments and Authentication

Payments and authentication were among the most sensitive capabilities.

Corporate customers needed confidence that:

only authorized users could request services;
transactions were associated with the correct account;
records could be reconciled;
sensitive data was protected;
changes were traceable;
access could be revoked;
administrative actions were controlled.

Legacy payment and authentication components had to evolve as the platform matured.

Replacing a critical system creates risk. Keeping it indefinitely creates another kind of risk.

The practical approach was incremental:

Identify the highest-risk limitations.
Establish clearer boundaries.
Introduce modern interfaces.
Migrate capabilities gradually.
Maintain traceability.
Avoid changing too many critical components at once.

The objective was not modernization for its own sake. It was to improve scalability, security, and control without destabilizing the business.

Building More Than an Engineering Team

As the product progressed, the organization expanded to approximately 50 professionals across:

engineering;
product;
design;
marketing;
commercial operations;
customer support;
administration.

Scaling changed the nature of the work.

In a small team, information moves through informal conversations. As the organization grows, that stops working.

We needed:

clearer responsibilities;
explicit priorities;
structured feedback;
one-on-ones;
development plans;
cross-functional coordination;
predictable decision-making;
stronger communication between business and technology.

Adding people does not automatically increase delivery capacity.

Without clarity, coordination cost can grow faster than output.

Leadership became less about personally solving each problem and more about creating conditions in which others could solve them.

Cross-Functional Leadership

The most difficult decisions rarely belonged to a single department.

A product change could affect:

engineering complexity;
customer contracts;
operational processes;
support workload;
marketing commitments;
financial reconciliation;
provider relationships.

Technical teams needed business context.

Commercial teams needed delivery context.

Operations needed visibility into product changes.

Product decisions needed to account for customer demand and platform sustainability.

Leadership was not about eliminating disagreement. It was about ensuring disagreement happened with shared information and explicit trade-offs.

Fundraising and Expansion

In 2015, I led a funding round that supported expansion.

Fundraising is often described as a milestone. It is better understood as a commitment.

New capital creates options, but also expectations around growth, execution, governance, and results.

The organization needed to translate investment into:

product development;
team growth;
commercial expansion;
operational capability;
customer acquisition;
reliability.

Capital does not solve a weak operating model. It amplifies the model that already exists.

If priorities are unclear, funding accelerates waste. If assumptions are weak, it scales the wrong solution. If leadership systems are immature, additional people increase confusion.

The funding round increased the importance of disciplined execution.

Commercialization

Turning a product into a commercial offering required more than releasing software.

Corporate customers needed confidence in the complete service:

demonstrations;
contract negotiation;
onboarding;
account configuration;
provider coordination;
support;
billing and reconciliation;
incident handling;
reporting;
relationship management.

The product became commercially real when companies incorporated it into daily operations.

By 2018, TecleTaxi supported multiple active corporate contracts.

That mattered more than whether every original feature had been implemented exactly as imagined.

Commercialization proved that the platform addressed a real operational need.

It also exposed the difference between adoption and operation.

Winning a contract creates the opportunity.

Delivering consistently creates the relationship.

Measuring What Mattered

We monitored indicators such as:

availability;
incident-resolution time;
customer satisfaction;
contract growth;
operational responsiveness.

Definitions mattered as much as values.

Availability could not mean infrastructure uptime alone. A platform might be technically online while payment, provider workflow, or authentication was unavailable.

Incident resolution could not mean merely closing a support ticket.

Useful metrics represent customer and business outcomes, not internal activity.

What Was Harder Than Expected

Enterprise Customers Need Predictability

Innovation attracts interest. Reliability, support, governance, and trust retain customers.

Operational Exceptions Become the Product

The expected workflow is simple. Complexity appears when a driver cancels, connectivity fails, payment is rejected, a journey is disputed, or a customer needs an exception.

The platform had to support the people resolving those situations.

Growth Exposes Organizational Weakness

A small team can compensate for unclear process through effort and proximity.

A larger organization cannot.

Architecture and Business Cannot Be Separated

A technical decision affects cost, delivery, workload, and commercial commitments. A commercial decision can introduce architectural complexity or security risk.

The Leader's Role Must Change

Being involved in every decision can initially provide speed and control.

Eventually, it creates dependency.

Leadership must move toward context, delegation, standards, feedback, and accountability.

Decisions I Would Preserve

Building Around a Real Business Constraint

The platform addressed corporate mobility rather than reproducing a consumer application for a different audience.

Choosing a Modular Architecture

Modularity preserved capability boundaries without introducing distributed complexity too early.

Treating Payments and Identity as Core Capabilities

They were central to trust and operational control.

Building Cross-Functional Capability

Engineering alone could not create a commercial platform.

Measuring Operational Outcomes

Availability, response, satisfaction, and contract development offered a more realistic view than feature delivery alone.

What I Would Approach Differently Today

Explicit Product and Domain Boundaries

Clearer ownership would reduce ambiguity as the platform and team expanded.

Stronger Observability

Technical metrics, business events, and customer-impact signals should be connected from the start.

Earlier Architecture Decision Records

Important trade-offs should be documented while context is fresh.

More Structured Experimentation

Product assumptions should be expressed as testable hypotheses.

Earlier Management Systems

Hiring and growth should be accompanied by explicit operating principles, roles, feedback cycles, and decision rights.

These are not criticisms made with hindsight. They are evidence that building a company changes how architecture, product, and leadership are evaluated.

Lessons From the Journey

A product is also an operating model. Support, contracts, onboarding, payments, reconciliation, providers, and incidents are part of the experience.
Architecture must match organizational maturity. The best architecture is one the organization can build, understand, operate, and evolve.
Enterprise trust is built through unremarkable capabilities. Authorization, reporting, reconciliation, auditability, support, and predictable operations enable adoption.
Growth requires leadership systems. A larger team needs clear ownership, expectations, feedback, communication, and decisions.
Funding increases accountability. Investment increases the cost of unclear priorities and weak execution.
Commercialization is different from development. The organization must sell, onboard, support, operate, bill, and retain.
End-to-end accountability changes technical judgment. Architecture cannot be evaluated in isolation from people, customers, operations, and capital.

How the Experience Shaped My Later Work

After the Managing Director role, I returned to software and solution architecture.

That transition may have looked unusual.

In practice, TecleTaxi made me a better architect.

I had learned to evaluate decisions through a broader lens:

customer value;
organizational capability;
operational risk;
delivery constraints;
financial sustainability;
team ownership;
long-term change.

Years later, while working with cloud platforms, data systems, and enterprise AI products, the underlying questions remained familiar.

Can the organization operate what we are designing?

Can users trust the result?

What happens when a dependency fails?

Who owns the outcome?

Does the complexity create enough value to justify its cost?

Technology changes.

The need for accountable engineering does not.

Conclusion

TecleTaxi Corporativo began as an attempt to solve a practical B2B mobility problem.

It became a lesson in product development, cloud architecture, payments, operations, fundraising, commercialization, team scaling, and leadership.

The most important outcome was not a feature or technology.

It was understanding that successful products emerge from the alignment of several systems:

software;
business model;
organization;
operational process;
customer relationship;
decisions made under pressure.

Building the platform required technical knowledge.

Commercializing and scaling it required something broader: connecting technology, people, capital, operations, and customer needs around a shared outcome.

That remains one of the most valuable lessons of my career.