Treat your storefront
as a product,
not a project
We assemble product, order, payment, settlement, and CRM modules into a D2C storefront. After confirming the integrations and brand experience you need, we separate standard modules from new development.
as the base structure
ReuseScope set by separating
standard features
Written into the contractCode, data, accounts
Operating terms agreed
Estimated separatelyPayment gateway, ERP, logistics,
and a review of existing data
A rented mall is too narrow,
and a full SI build is too heavy
The limits of a rented mall
Hosted SaaS lets you start quickly within its features and operating policy, but brand-specific features and external integrations can run into constraints.
The weight of building your own
A bespoke build swings widely in schedule and cost depending on features, data migration, integrations, security, and approval scope. Operational readiness has to be planned alongside.
Starting from scratch every time
Redefining shared functionality such as products, orders, payments, and settlement every time leaves less room for the experience that is actually your brand.
Mallkit is the four-stage Bespokit generation pipeline with commerce domain design and standard modules on top. Requirements, acceptance criteria, the repository, and the handover scope are managed in the same flow.
It starts with a conversation
and ends with a launch
Define it in conversation
Brand, product structure, and how you sell get organised through conversation. If you already have a plan or benchmark links, put them straight in.
Design the commerce spec
The complexity specific to commerce, such as product options, delivery policy, and promotion rules, is organised into standard design documents and reviewed.
Assemble modules and generate code
Commerce modules are assembled and brand-specific features are separated into their own development scope. Payment and logistics integrations are checked against each service's API and authentication conditions.
Launch and operate
Infrastructure and deployment environments are configured, then it launches after operator review. Features added after launch are managed against the same spec and repository.
What every storefront needs
is already built
Modules refined on real commerce projects, provided as standards.
Products and options
Multi-level options, inventory sync, sold out and restock handling
Orders and claims
Order flow, cancellation, exchange, and return processes
Payments and settlement
Payment gateway integration, amount precision, idempotency, compensation handling
Inventory and delivery
Inventory tracking, carrier integration, delivery tracking
Promotions
A rules engine for coupons, points, and tier discounts
Members and CRM
Customer segments, purchase history, message delivery
Admin console
The screens operators use daily, laid out along the actual workflow
Data and analytics
Revenue and conversion dashboards, raw data retention and export policy
Compare the approaches
on operating criteria
| Criterion | Hosted SaaS | Conventional bespoke build | Mallkit |
|---|---|---|---|
| Starting conditions | Configured within the plan and its settings | Estimated after confirming requirements and approval scope | Estimated by separating standard modules from new development |
| Custom features | Limited to the provided options and API surface | Design and development quoted per feature | Additional development managed from the standard spec and repository |
| Code and data | Subject to the provider's terms and export policy | Subject to the project contract | Handover scope and operational responsibility written into the contract |
| After launch | Subject to the provider's releases and operating policy | Subject to the maintenance contract | Change managed against the same spec, documents, and repository |
Commerce experience
that reached launch
Piuda: D2C platform build and launch
We built the D2C storefront platform and stayed through the market launch.
HPPY · Yangmar
Ecommerce operations tangled across sales channels, orders, and settlement, consolidated onto one platform.
A support agent in the same build
An AI agent that links order and delivery enquiries to their evidence can be scoped into the storefront build.
Frequently asked questions
The conditions people check most often before adopting.
How is Mallkit different from a hosted shopping mall?
Hosted SaaS is a way to start quickly within the features and operating policy it provides. Mallkit sets a bespoke build scope on top of standard commerce modules, including brand-specific features and external integrations, and writes the handover terms for code, data, and operational responsibility into the contract.
Which commerce features are in the default scope?
We review against products and options, orders with cancellation, exchange and return, payments and settlement, inventory and delivery, members and CRM, promotions, admin, and analytics. What is actually included is set against your business model and operating process.
Can you integrate payment gateways, ERP, and logistics?
Yes, after checking each service's API, contract status, authentication method, and data formats. Anything requiring new development or a separate service fee is itemised in the quote.
Can we migrate existing member, product, and order data?
We start by checking the quality of the source data and whether it can be extracted. Field mapping, cleansing, a test migration, the cutover point, and post-migration verification are estimated as their own scope of work.
How are timeline and cost decided?
They depend on how far the standard modules apply, brand design, external integrations, data migration, security and authentication, and operator review conditions. After confirming requirements we propose the standard configuration and the additional development separately.
Let us map the storefront scope
starting from how you operate
Tell us about the brand and the products, and we will propose a launch schedule and a quote.