T-shaped developers in mobile commerce: team model, risks and a CTO checklist

A T-shaped developer has vertical depth in one discipline and horizontal breadth across several neighbouring areas. In mobile commerce, that can mean a senior React Native engineer who understands native iOS/Android constraints, API contracts, cart behaviour, payments, analytics, App Store/Google Play release and how ERP integration decisions surface in the app.

This is not a cheap substitute for a team. The value of a real T-shaped profile is that they see dependencies between layers sooner. When checkout in the app fails after a B2B pricing change, they do not stop at "backend issue". They check cart state, token, pricing rule, ERP sync, telemetry, cache and the missing regression test.

For a software buyer, that distinction matters. If a vendor sells "T-shaped" as one developer who will design UX, build the app, backend, integrations, QA and DevOps alone, that is not a team model. It is risk moved onto one person.

A commerce app is not just a frontend on a phone. It connects catalogue, prices, promotions, inventory, cart, payments, login, push, analytics, deep links, consent, store review, crash reporting and often the same processes used by the web store or B2B portal.

React Native and Expo shorten delivery across iOS and Android, but they do not remove system boundaries. Sometimes a library is enough, sometimes a Swift/Kotlin native module is required, sometimes the issue is backend, and sometimes it is the data model. Expo documents that most apps do not need native code, but when no library fits or a company SDK must be wrapped, the team must understand the native layer.

In headless or composable commerce, integrations add another layer. Medusa describes modules as packages of functionality tied to a domain or integration; in real projects those domains are not business-neutral. A pricing-module change affects margin, cart, invoice, credit limit and the message shown in the app. A T-shaped senior shortens the distance between a technical choice and the business consequence.

A T-shaped profile helps most when a feature crosses many layers. Example: a loyalty program in the app needs a screen, API, point rules, analytics events, push messaging, regression tests and offline behaviour. Without breadth, the work easily becomes ticket ping-pong.

The second case is discovery and estimation. A senior who has seen app store release, payment timeouts, token refresh, webhook retries and cart edge cases can say early: "this feature looks simple in UI, but touches three systems of truth". That lowers fixed-price risk because scope is based on dependencies, not only the mockup.

The third case is incident response. When Black Friday or a push campaign creates a traffic spike, you want someone who can read crash logs, API latency, queues, payment errors and user behaviour in the funnel. DORA measures delivery through throughput and instability, including lead time, deployment frequency, recovery time and change fail rate. A T-shaped team should improve those metrics, not just have a nicer role description.

The biggest red flag is a shallow T: someone knows tool names, but lacks production depth. That profile may build a demo, then break under the first security review, unusual payment SDK, catalogue performance issue or conflict between ERP state and the app.

The second red flag is a single point of failure. If one person understands the app, API, release, integrations and business conversations, the project may look fast for two months and then slow down because all context runs through one calendar. Team Topologies highlights cognitive load: overloaded teams make poorer decisions and move more slowly. The same applies to an overloaded senior.

The third red flag is a missing Definition of Done. The Scrum Guide emphasizes cross-functional, self-managing teams and shared quality. In mobile commerce, "done" must cover not only code, but telemetry, regression tests, accessibility, consent, app store readiness, rollback and customer-support communication.

A strong mobile commerce team combines T-shaped seniors with narrow experts where error cost is high. A narrow expert makes sense for security review, database performance, native iOS/Android modules, payments, accessibility, data engineering, load testing, app store compliance or complex ERP integrations.

A T-shaped senior should know when to ask for that expert. That is often the most important interview signal. The question is not "can you do everything?", but "how do you know this needs a specialist, and how do you define the working contract with them?".

For the client, the practical model is simple: the T-shaped core team owns the product and end-to-end decisions, while specialists enter specific risky domains. You avoid burning budget on a full expert bench from day one, but you also avoid pretending that one generalist can solve every problem.

Do not start with a framework list. Start with production stories: checkout outage, app store release problem, payment bug, ERP integration, conversion drop after a UI change, regression after an SDK update. A real T-shaped profile can explain how they diagnosed the issue across layers and what they changed so it did not return.

• Ask for a decision where UI, API and business had conflicting needs.
• Ask which metrics they watch after a commerce-app release.
• Check whether they understand the difference between a demo flow and production checkout.
• Ask for a situation where they refused to ship without an extra test or specialist.
• Ask how they document API contracts and integration ownership.
• Check whether they discuss source code, handover, observability and maintenance, not only sprints.

At GMI, we do not sell raw "developer capacity" as the main story. For mobile commerce, we start with Discovery, Design & Technology: we map the business, users, processes, risks, integrations, app store requirements and success metrics. Only then do we shape the team and scope.

A typical core is a tech lead or T-shaped senior, React Native/Expo, backend/API, QA, design/product and a client-side owner. We add specialists when discovery shows risk: MedusaJS/headless commerce, NestJS, PostgreSQL, ERP/PIM/WMS, security, performance, native module or observability.

After DDT we can discuss fixed price because dependencies are known. The client receives source code, contract documentation, architecture decisions and a maintenance plan. That limits vendor lock-in and reduces the risk of the "T-shaped team" becoming a black box.

Use this checklist before signing a vendor agreement or adding people to the internal team. If the answers are unclear, you do not yet have a delivery model; you only have a role list.

• What is the depth spike of each key team member: mobile, backend, commerce, QA, DevOps, product?
• Which breadth areas are required in this project: UX, analytics, app stores, ERP/PIM/WMS, observability, security?
• Where do we have a single point of failure, and how do documentation, review and rotation reduce it?
• What is the Definition of Done for checkout, login, payments, push and order history?
• Which delivery metrics will we track: lead time, deployment frequency, recovery time, change fail rate, crash-free users?
• Which risks require a narrow expert, and which can the T-shaped core team handle?
• What does the client own after the project: source code, runbooks, API contracts, tests, dashboards, maintenance backlog?