TypeScript has become large enough to support several very different kinds of development business.
A consultancy can build custom applications with Next.js, TanStack Start, React Router, PostgreSQL and the surrounding Node.js ecosystem. The client brings a business problem, and the technical team decides how the application should be built.
The same consultancy can also specialize in business platforms such as Payload, Medusa or Vendure. In those engagements, the customer may already have selected the technology before looking for an implementation partner.
Those are two different commercial models living inside much of the same technical ecosystem.
text
PLATFORM SPECIALIST
Business problem
↓
platform selected
↓
implementation partner selected
CUSTOM APPLICATION BUILDER
Business problem
↓
implementation partner selected
↓
architecture selected
This distinction does not cover every way to make money with TypeScript. Product companies, SaaS businesses, staff augmentation firms, training companies and conventional development agencies all sit outside it. A consultancy can also operate both models at the same time.
The useful question is where you want your expertise to compound.
TypeScript now reaches well beyond frontend development
For a long time, TypeScript could easily be treated as part of the frontend stack.
Today, that description leaves out a substantial part of the ecosystem.
A developer can remain largely inside TypeScript and JavaScript while moving between websites, CMS platforms, ecommerce systems, back-office applications and custom business software.
At the application-framework layer, there is Next.js, React Router and the emerging TanStack Start.
At the business-platform layer, there are products such as Payload, Medusa and Vendure.
These products solve different problems, and they share enough underlying engineering that knowledge transfers freely between them.
You repeatedly encounter TypeScript, Node.js, React, SQL databases, authentication, APIs, background jobs, integrations, deployment and testing.
That creates an interesting choice for a service provider. You can specialize around the tools used to build applications, or around applications that already solve a recognizable business category.
Model one: become the specialist for a business platform
A company evaluating Payload, Medusa or Vendure often settles on the product before it starts looking for an implementation partner. The provider's work begins once that decision has already been made.
For a content platform like Payload, that work can involve far more than installing a CMS. A serious Payload project may include content modeling, migrations, localization, permissions, editorial approval workflows, digital asset management, custom administration interfaces, integrations, hosting, preview infrastructure and production deployment. The platform solves a large amount of generic CMS infrastructure. The implementation partner works on how that infrastructure should serve the business.
Commerce platforms create the same pattern in a different domain. A company adopting Medusa may need custom catalog structures, ERP integrations, B2B pricing, fulfillment logic, checkout behavior, marketplace functionality or operational tooling. Medusa's own published implementation material includes ERP integrations built for enterprise and B2B commerce, including distributor ERPs, inventory synchronization and custom pricing flows — the kind of work that only shows up once a project moves past a basic storefront.
A Vendure implementation follows a similar arc: product modeling, inventory, custom order processes, ERP integration, pricing rules, B2B account structures and extensions to the administration interface. The technical work becomes increasingly specific to the platform as the project becomes more sophisticated.
That creates the possibility of accumulated implementation knowledge. After several projects on the same platform, an experienced specialist may have already encountered the same categories of problem:
Some of those lessons become reusable code. Others become architectural judgment. The second category is often more valuable. Knowing where a platform becomes difficult, which extension point is appropriate, where integrations tend to fail, and which architecture survives upgrades can reduce uncertainty on future projects — and that kind of knowledge is difficult to acquire from documentation alone.
How far platform specialization can go
Vendure provides an unusually clear example of where this can lead.
The company behind Vendure published the history of Elevantiq, the software agency closely connected to Vendure's development. Elevantiq began as a broader development company and gradually concentrated on increasingly complex B2B ecommerce work, with Vendure becoming central to that specialization. According to Vendure's account, Elevantiq grew into a profitable agency approaching €3 million in annual revenue before the team eventually closed the agency and moved its focus fully onto Vendure.
That case needs careful interpretation. Elevantiq's relationship with Vendure went beyond a typical implementation partnership: the agency became financially and organizationally connected to the platform itself. The €3 million figure describes that one unusual case. As an illustration, it marks a ceiling — how far a business domain and a platform can fuse together when the specialization runs deep enough for long enough.
The buyer has supplied more information than someone searching for a generic developer — the named technology becomes part of the request itself. How that translates into conversion rate or deal size depends on search volume, competition, platform adoption and project economics, all of which vary between products. The consistent part is smaller in scope: a platform gives buyers an additional vocabulary for describing the expertise they're looking for.
Vendors increasingly reinforce this channel through partner directories, implementation programs, case studies and referrals. Payload's agency partner program is one visible example of a vendor formalizing this market; commerce platforms build similar referral and case-study ecosystems around their own implementation partners as adoption grows. This lets a consultancy position itself at the intersection of a product and a business problem:
That combination usually says more about capability than a label such as "React agency."
Model two: build the application yourself
The second model starts earlier in the technical decision process. The customer may arrive with requirements such as:
We need a distributor portal.
We need a customer account application.
We need an internal approval system.
We need software for managing inventory across these locations.
There is usually no preselected application platform. The consultancy owns much more of the architecture: it might choose Next.js, TanStack Start or React Router as the application framework, PostgreSQL as the primary data store, and Redis or a queue for background processing. Authentication, object storage, observability and third-party APIs get selected around the needs of the system.
In this model, the choice between Next.js and TanStack Start usually matters more to the engineering team than to the business buyer, who is primarily buying the resulting software. That shifts where expertise accumulates. A custom application consultancy develops deeper knowledge around architecture, discovery, domain modeling, integrations, user experience and operational reliability. Its reusable assets look different from a platform specialist's — internal libraries, deployment templates, authentication patterns, integration infrastructure and testing or observability approaches that travel across client engagements.
Because there's no preselected product, discovery work carries more weight here than in a platform engagement. A team has to figure out what the business actually needs before it can propose an architecture, and that judgment is harder to demonstrate up front than a platform name. Reputation tends to travel through referrals, a track record in a particular vertical, or a pattern of solving one recognizable category of problem well — a distributor portal here, an internal approvals system there.
A platform such as Vendure already knows what an order is. Payload already provides concepts for content collections, access control and an administration interface. A fully custom application begins with fewer assumptions, so the development team has to decide which concepts the system needs and how those concepts interact. That's the trade the consultancy makes for architectural freedom: more of the addressable market opens up, and the provider carries more of the judgment about what to build, since no platform is carrying it already.
The difference is who makes the product decision
This is the cleanest way to distinguish the two service models — and it comes down to sequence.
text
PLATFORM-LED
Business problem
↓
platform selected
↓
implementation partner selected
CUSTOM APPLICATION
Business problem
↓
implementation partner selected
↓
architecture selected
With platform-led work, the technology decision can happen before the implementation partner is even in the room. With custom application development, the provider usually participates directly in that decision. That single difference shapes how each business develops expertise.
A platform specialist can build product-specific case studies, implementation tooling, vendor relationships and knowledge of recurring platform constraints. Its market is tied more closely to the health of the platform — changes in adoption, pricing, roadmap or ecosystem competition can affect demand in ways the specialist doesn't control.
A custom application consultancy has more architectural independence and can address problems across a wider technology landscape. It needs another way to establish specialization, which may come from a vertical market, a category of application, integration expertise, or a reputation for handling a particular kind of technical complexity.
Both models reward depth. They simply concentrate that depth in different places.
TypeScript makes moving between the models unusually practical
One reason this distinction is particularly workable inside the TypeScript ecosystem is the amount of technical overlap underneath it.
Payload, Medusa and Vendure operate in the broader Node.js and JavaScript environment. Next.js, TanStack Start and React Router live in that same environment. A developer moving between these products continues to encounter familiar foundations:
The business domain can change substantially — editorial permissions and localization on one project, pricing and inventory on the next, a fully custom internal tool after that — without requiring a complete change of engineering ecosystem. The underlying language, debugging tools, deployment practices and infrastructure stay largely familiar.
Similar combinations of application frameworks and business platforms exist around PHP, Python, Java and .NET. Inside TypeScript, these particular layers currently overlap closely enough that a Payload specialist can pick up Vendure without leaving the language, and a Vendure developer can still build a fully custom Next.js application on the side. That continuity is what lets a consultancy expand the business problems it takes on without starting its technical education over.
Platform and custom work can also exist inside the same project
The boundary between these models is sometimes porous, and the two frequently show up together inside a single engagement.
Consider a B2B commerce application built on Vendure. The platform might provide catalog management, pricing, orders, inventory and administration, while the project still requires a completely custom customer portal, quotation process, approval system or integration layer. The result contains substantial custom application engineering built around a specialized commerce platform.
The same pattern shows up with Medusa, where the core commerce engine can sit underneath a fully custom storefront, a bespoke B2B ordering flow, or an operational dashboard that has no equivalent in the platform's own admin. And it shows up with Payload, where the content system, users, permissions and administration experience can anchor a customer-facing application that contains significant custom business logic of its own.
A useful architectural question follows from this:
Does an established platform already solve the expensive, generic part of this problem well enough to justify building around it?
When the answer is yes, a platform can remove years of infrastructure work from the project. When available platforms fit poorly, custom application development gives the team control over the domain model and architecture. A consultancy does not need a permanent ideological position on either approach — the decision can be made project by project.
Where should your expertise compound?
There are two valuable directions available to a TypeScript service business.
One develops deep expertise around named platforms such as Payload, Medusa and Vendure. The platform becomes part of the consultancy's positioning, implementation knowledge and potentially its acquisition channels.
The other develops deep expertise in designing custom systems with frameworks such as Next.js, TanStack Start and React Router. Its differentiation comes from architecture, domain understanding and the ability to turn unusual business requirements into reliable software.
Many strong consultancies will eventually operate across both. TypeScript makes that combination practical because the underlying engineering environment stays relatively consistent across content systems, commerce platforms and custom applications.
The useful decision is where you want your expertise to compound: around a product ecosystem, around a class of business problems, or deliberately across both.
