One platform, thirteen trades: Welkent's module marketplace

Welkent covers thirteen main trades: VVS, el, tømrer, murer, maler, tagdækker, kloak, gulv, smed, glarmester, snedker, brolægger, and anlægsgartner. A heat-pump installer and a landscaping company have almost nothing in common in their day-to-day work, but they both need to quote jobs, invoice customers, and track materials. Building thirteen separate products would mean thirteen separate places for bugs, thirteen onboarding flows, and thirteen times the maintenance burden for the parts every trade actually shares.

Welkent's answer is a module marketplace sitting on top of one shared platform.

Shared core, trade-specific modules

The platform itself, quotes, invoicing, customers, scheduling, is trade-agnostic. What's trade-specific lives in modules: a heat-pump module with BBR-driven building data and subsidy calculations, a solar module, an insulation module, and so on. An account activates the modules that match what they actually do, and the trades they haven't touched simply don't clutter their interface.

Modules aren't all built the same way. Some are Welkent-owned, built and maintained centrally because the underlying calculation (DS 1150 heat-requirement math, for instance) is complex enough that it needs to live in one place and be correct everywhere. Others are structured so an account can acquire and configure their own variant, useful for trades where the "calculation" is really just a company's own standard pricing and scope rather than a regulated formula.

What doesn't fit a module: the free-form Tilbudsbygger

Not every job fits a structured calculator. A murer quoting a bespoke facade repair, or a snedker pricing custom kitchen cabinetry, isn't running a heat-pump-style dimensioning formula, they're assembling line items, materials, and labor into a quote that's different every time.

For that, Welkent has Tilbudsbygger, a free-form quote builder that works the way a spreadsheet-and-Word workflow used to, but backed by the same customer records, catalog pricing, and PDF/MitID-signing pipeline as every trade module. It's the fallback that keeps the platform useful for the long tail of work that doesn't justify its own dedicated module, without forcing every trade into a one-size-fits-all wizard that doesn't match how their jobs actually get priced.

Why this shape, not thirteen products

The alternative, building each trade as its own product, would duplicate everything that isn't trade-specific: authentication, customer management, invoicing, the PDF and MitID-signing pipeline, materials pricing. None of that benefits from being reimplemented per trade. What does benefit from separation is the actual domain logic, a heat-pump calculation has nothing in common with a landscaping quote, and forcing them into one shared calculator would make both worse.

Splitting along that line, shared platform underneath, trade-specific modules on top, plus a free-form builder for whatever doesn't fit a module, lets Welkent add new trades without touching what already works for the other twelve. It's also what makes the platform's account-level module system possible in the first place: an account only sees and pays for what applies to their business, not a generic tool trying to be everything to everyone.

Read more about the full operations platform this sits inside.