Wholesale e-⁠commerceand web applicationstailored toyour needs

In headless stores the Medusa backend exposes an API and the store is a separate app, usually in Next.js. One backend can serve wholesale and retail across markets with their own currencies, as at Crème Bar, and a Next.js front end runs at Oponykola, among others. For a simple single-channel store we say plainly it is overkill.

Medusa is our main platform for stores and wholesale shops: customer groups with price lists, separate sales channels and our own modules without touching the core. We write plugins for it: the Medusa team featured five in its directory, and you can click through most in our demo. Oponykola and Crème Bar run on it, among others.

We choose Payload when editors need a comfortable panel and content should stay in the system's own database. That is the case in the Wekert app, where the blog and the Next.js panel read content from PostgreSQL.

We build Shopify themes for the brand instead of buying ready ones, with custom blocks such as specs from metafields or “Buy now” straight to checkout. Shopify can also be the sales back end behind a Webflow front, as at Astriva. When a store outgrows the platform we move it on, like Oponykola to Medusa.

Storesynk brings Shopify products into the Webflow CMS and adds variants, cart, discount codes and customer accounts without embedded widgets. Koda Plus is listed in Storesynk Experts as the only company from Poland. We deployed it at Astriva, in four languages.

We build Webflow sites on a structured class system, with CMS collections editors update without a developer and language versions through Localization. A unit's colour on a floor map can come straight from its CMS status. WJ Investment, JW, Astriva and Solski Communications were built this way, among others. We hold the Webflow CMS and Layouts certificates.

We do not build new stores on WooCommerce, we move them to Medusa or Shopify: an inventory of URLs, data and forgotten integrations, a 301 for every URL, products, customers and order history, and indexing checks after the switch.

Price lists in our Medusa wholesale shops are built on native price lists tied to customer groups, with quantity tiers and negotiated prices. The KODA SUPPLY demo runs B2B Standard and Premium plus a framework agreement, and price negotiation is a separate plugin of ours.

In our Medusa wholesale shops a logged-in business sees net prices from its price list, and a retail buyer sees gross prices. The KODA SUPPLY demo works that way: net catalogue, 23% VAT added in the cart, and one rounding method from cart to invoice.

We map wholesaler feeds onto store categories, match products by EAN or SKU and price them with margin rules. Before the nightly import we compare file size and item count with the previous run, so a truncated file cannot wipe half the catalogue.

The balance and open invoices stay in the ERP, and the Medusa store pulls them in and enforces the limit: over it, the cart blocks, goes to the account manager for approval or offers prepayment. Trade credit is also one of our Medusa plugins.

A migration starts with an inventory of data, integrations and URLs with traffic. Every URL gets a 301, we build the new store alongside the old one, and data goes through a trial run checked by the numbers. That is how we moved Oponykola from Shopify to Medusa and the Solski Communications blog from WordPress to Webflow.

Abandoned cart reminders show customers their own items and go out at most once per cart, only for carts idle 24 to 72 hours. That is how our e-mails plugin works in the Medusa demo, and in UX audits we look for where buyers drop off.

In wholesale shops we add quick ordering above the cart: a list of SKUs pasted from a sheet, a file, a repeat of the last order or a saved cart for regular deliveries. Items are priced by the customer's own list, as you can see in the KODA SUPPLY demo.

Sign-up by tax ID is standard in our wholesale shops: address data fills itself, the status is checked on the VAT whitelist and EU companies in VIES. The account waits for approval. It works in the KODA SUPPLY demo, and VAT Whitelist is one of our plugins featured by Medusa.

We connect Allegro to stores through the API or via BaseLinker, depending on whether a ready connector can handle the price and stock rules. Product attributes are suggested from Allegro categories, and offers are read back on a schedule. We also have our own Allegro plugin for Medusa. Oponykola sells this way, among others.

BaseLinker runs the warehouse and marketplace sales, and the store syncs with it instead of counting stock separately. Our Medusa module queues operations, respects the API limits and logs every exchange. Oponykola works this way, and at Abrams BaseLinker ties the catalogue to the central warehouse.

We connect Optima to stores and wholesale shops so customer price levels, discounts and limits work one to one in the store, and document numbers come back to the customer account. The data map follows Optima's limits on custom price lists and records.

Flat prices reach the dane.gov.pl register every day with no manual uploads: the dataset points to a fixed address on the developer's domain, and the portal pulls the daily CSV files itself. The price transparency law requires it. The WJ Investment and Firma Inwestycyjna JW sites work this way.

Fakturownia is the accounting layer of a store for us: order data reaches it with the buyer's tax ID, and the document is created on a status change, with no retyping. Our Fakturownia plugin for Medusa, featured by Medusa, issues one invoice per order and shows the KSeF status. Crème Bar uses it, among others.

We build InPost on the ShipX API without all-in-one plugins: Geowidget in checkout, shipment, PDF or ZPL label and tracking. That is how our InPost plugin for Medusa works, featured by Medusa, and in the demo store you pick a locker at checkout.

The KSeF number comes back to the order: in our Subiekt nexo integration the bridge sends it to the store with the invoice, and the Fakturownia plugin shows the KSeF status in the Medusa admin. We plan for corrections, offline mode and separate B2B and B2C paths.

We connect OLX in the same BaseLinker catalogue as Allegro, so the listing, the offer and the store share one stock level, with no separate sync per site. It matters for single-item stock, like the tyres and rims at Oponykola. We also have an OLX plugin for Medusa, featured by Medusa.

We plug Przelewy24 into Medusa as a payment provider with BLIK and bank transfers: the backend places the order on the gateway notification, and the return page waits for confirmation and checks the status itself if needed. Polish Crème Bar customers pay this way, next to Stripe.

Resend sends the koda.plus contact form messages: a notification to the team and a confirmation to the sender, via the REST API from a Cloudflare function. Our Medusa e-mails plugin runs on it too, showing order, shipping and abandoned cart templates in the demo.

We keep Sellasist as the place where the team handles orders and shipping. The AI agent takes no action there: cases that need it, such as returns or complaints, go to people. That is how it works at Abrams.

We connect Stripe through the Medusa payment module with Payment Element, and a webhook completes the order if the customer never returns from the bank. Our Stripe plugin shows fees, disputes and payouts in the Medusa admin, read only. At Crème Bar Stripe takes payments on every market, euro included.

We connect Subiekt nexo to Medusa with our bridge built on Sfera: orders land in Subiekt as sales orders, and dispatch notes, invoices and KSeF numbers come back to the store. The plugin, featured by Medusa, shows its document queue in the demo. The Crème Bar store works with Subiekt nexo, among others.

koda.plus runs on Astro, hosted on Cloudflare: static HTML, local fonts, CSS and GSAP animation, and JavaScript only in the components that need it. We build client brand sites the same way when SEO and Core Web Vitals matter.

We design in Figma ready for a 1:1 build: components, screen states and tokens that share names in Figma and code, and clients get the files unlocked. koda.plus was built that way, and for SpaceForm we settled the section layout in Figma before the build, since both investors and engineers read the site.

GSAP reveals koda.plus sections on scroll and choreographs the hero. At WJ Investment it splits headings into words and turns them in one by one, and at Solski Communications a line by each section heading grows from a single site-wide interaction.

We use Lenis on sites with a rich visual layer, where smooth scrolling supports the content, and only when it does not get in the way of reading. It runs on the Webflow site of the ballistic protection maker Astriva, among others, with its catalogue of plates and vests and its lab sections.

We choose Next.js when a site becomes an app: accounts, a data panel, integrations. Rendering is set per route, because making everything dynamic is the most expensive option. The Oponykola front end with its own catalogue index and the Wekert panel work this way, among others, while the AMARACH TIM site is fully pre-generated.

We use React where the interface has state and logic: a cart with live stock, several payment paths, editors and planners in panels. On Astro sites like koda.plus we use it only where needed. It runs in the Crème Bar store, the Wekert panel and Koda Flow, our own product, among others.

We use Tailwind on React and Next.js projects with many repeated components: brand colours and fonts are defined once in the theme, so every card keeps the same look. The AMARACH TIM site was built this way. koda.plus, on the other hand, has its own styles with no CSS framework.

Koda Flow, our own product, runs on Tauri and React: a transparent Windows overlay, always on top and click-through, that reduces motion sickness when working on the move. A WebSocket server in the Rust layer receives motion from the phone.

three.js powers the 3D plus on koda.plus, in the home hero, on service pages and on the About page. It loads lazily after the page, and with reduced motion turned on the scene does not load at all.

We add Algolia to headless stores when built-in search is no longer enough: one index per language, typo tolerance and index updates right after a product changes in Medusa. Queries go through the backend, which picks the index by page language. That is how the three-language Crème Bar catalogue works.

koda.plus runs on Cloudflare: Astro with the Cloudflare adapter and a contact form as a server function behind Turnstile. Our Medusa demo store is served from there too, and Astriva's Webflow site is published through Cloudflare as cached HTML.

New Medusa stores and wholesale shops go on Medusa Cloud: usually the Launch plan, Scale with a separate worker for heavy ERP integrations. Clients approve changes on preview environments, and we move older Railway stores over without rewriting the app.

PostgreSQL is the database behind every Medusa store we ship, and at Oponykola, Wekert and Abrams it runs on Railway next to the app. Data stays in a standard database, so changing hosting never means changing platform.

We pick Railway when a project needs a process running nonstop, not just a static front end: a backend with a database, scheduled jobs, webhooks at any hour, PDFs in headless Chromium. It hosts the Oponykola backend and front end, the Abrams AI agent hub and the Wekert app, among others.

We pair Supabase with Webflow when a site needs its own database next to the CMS. It holds what the CMS cannot, such as the price history of every unit with change dates, linked to its CMS entry, and the daily dane.gov.pl dataset is built from it. The WJ Investment and Firma Inwestycyjna JW sites work this way.

Next to Cloudflare, Vercel is one of the two places we host Next.js front ends: the prerendered page is served from edge cache with no server to maintain. The client owns the code and access, so it can stay or move. The AMARACH TIM site runs this way.

We start with robots.txt, separating model-training crawlers from search agents such as OAI-SearchBot and PerplexityBot. The answer goes right under a heading phrased as a question, and we regularly check the brand in AI answers against real customer questions and server logs.

We do not run campaigns, we build their technical side. In the Wekert panel, read-only Google Ads API results sit next to site enquiries, and rules turn the metrics into short advice, for example on a campaign spending budget without conversions.

We set up Search Console with GA4 and Tag Manager on every launch. Its reports start every SEO audit, and after a store migration we watch indexing, 404s and redirects there for the first weeks.

After every koda.plus deploy our script collects URLs from the sitemap and submits them to IndexNow. It fetches the sitemap past the Cloudflare cache, which can return the old one right after a deploy, and we pass retired 301 URLs to it directly.

koda.plus has its own llms.txt: services linked to the offer, technologies, common questions, company details and a short English summary. We treat it as an extra, not a substitute for work on content and structured data.

koda.plus publishes an Organization and WebSite graph plus BlogPosting on posts, and our audit script flags pages without JSON-LD. In stores we keep Product markup in line with feed price and stock, and on migrations we compare old and new structured data.

We check our own site with a script that walks every sitemap URL and verifies titles, descriptions, canonical, hreflang and JSON-LD. For clients we start from server logs and Search Console, and in stores we cut filter URLs that waste crawl budget.

We run the koda.plus blog on topic clusters: phrases come from Google suggestions collected by our own script, and posts are based on what we did in real projects. AI helps with research and drafts, but the examples and editing are ours.

An AI agent drafts answers from the catalogue, price lists and order history and hands harder cases to people. In-house we run several agents in parallel: each starts from the vault, and we check everything they deliver in code review. At Abrams (electronics, home and garden) one agent covers the store and Allegro.

Security-focused AI agents review code and infrastructure at every stage, and our team approves the changes. The koda.plus form is protected by a honeypot and Turnstile, and the Abrams AI agent gets only the data a case needs and never acts on orders.

The AI chat answers from store policies and order data, and when a case needs action it hands it to the team with the channel it came from. Delivery and returns rules are written once for every channel. We deployed it at Abrams, where it talks to customers in the store and on Allegro.

On the Claude API we build agents in a tool loop: the model decides whether to search the knowledge base, check an order or hand the case to a person, and answers from company data, not memory. We also use Claude for our own code. For client projects we pick the model by their requirements.

Several AI agents work with us in parallel, and we check everything they deliver against the vault instructions. Without our team's approval in code review nothing reaches production. We can also join a client's review process or audit existing code.

Through MCP we give AI agents access to the tools and data a specific task needs, for example when analysing a company's business logic. On Medusa stores we can expose chosen data and operations through an MCP server, so the assistant stays within set permissions.

The KODA Vault you are looking at is our Obsidian knowledge base: standards, playbooks and decisions from projects that AI agents get at the start of each job. For Wekert we built Obsidian-style notes where a checkbox becomes a task in the planner.

We split a project into slices such as price lists, ERP integration, tests and SEO, and each gets its own AI agent working in parallel. All start from the same vault, while assembly, architecture and code review approval stay with our team.

Every project adds standards, decisions and proven modules to the vault, and AI agents get them at the start of the next one. That way lessons from one store, such as BaseLinker API limits or Subiekt integration, carry straight into the next.

We test changes to live stores on an environment that mirrors production. Tests are a separate slice for an AI agent, and we review the result ourselves. Bigger features go first to selected customers, and there is always a rollback path.