From “Buy” to a physical object: engineering a platform that prints across the internet

What The Genesys does

The Genesys is a marketplace for 3D-printable designs. Creators upload models, configure variants and pricing, and publish them to a storefront. Buyers purchase the right to print a design — paying with Stripe, an in-platform virtual currency (G-Coin), or Apple and Google in-app purchases from the mobile app — and then press Print. The platform slices the model in the cloud, encrypts the result, and streams it to a small hub device (called Hermes) sitting next to the buyer's 3D printer. The printer starts. Progress and time-remaining tick along live in the mobile app until a physical object exists.

That single sentence hides four products: a React creator platform, a WordPress-based storefront, Flutter apps for iOS and Android, and a custom Linux device with its own operating system image.

Why this is genuinely hard to build

Most software never has to touch the physical world. A connected-hardware marketplace has to solve problems that no SaaS template covers:

• Trust between services. A dozen microservices ask each other to mint tokens, transfer ownership, and move money. Every one of those requests has to be provably from the service it claims to be from.
• Trust across the internet's last metre. A creator's intellectual property is being sent to hardware in a stranger's home. The design must be printable there without ever being possessable there.
• Heavy compute on demand. Slicing an STL into printer-ready GCode is CPU-hungry and slow — it can't live inside a request/response cycle.
• A fleet you can't touch. Once the hubs ship, every bug fix, config change, and feature has to reach devices you will never physically see again.

The platform at 10,000 feet

Everything server-side runs on Amazon EKS (Kubernetes), spread across three availability zones inside one VPC. Traffic enters through Route 53 and CloudFront, passes a WAF, and lands on load balancers in public subnets; every workload node lives in private subnets with no public IPs. Karpenter provisions compute dynamically: stateful services (PostgreSQL-adjacent infrastructure, RabbitMQ, Redis, Keycloak) stay on on-demand instances, while stateless microservices run two replicas each — one on on-demand, one on spot — so the platform gets spot-instance economics without spot-instance fragility.

Delivery is GitOps end to end. A merge to an environment branch triggers a CI pipeline that builds the Docker image, scans it for vulnerabilities with Trivy, pushes it to ECR, and bumps the image tag in a separate infrastructure repo. ArgoCD watches that repo and syncs the change into the right namespace — nobody runs kubectl apply by hand, and every deployment is a reviewable Git commit. Secrets never live in repos: they sit in HashiCorp Vault and AWS Secrets Manager and are injected into pods by the External Secrets Operator. Observability is Prometheus and Grafana for metrics, Loki for centralised logs, with monitoring workloads isolated on their own tainted node pool.

A dozen services, two ways of talking

The backend is a monorepo of focused Node.js/TypeScript microservices: a Creator API (the domain core), Authentication, Handshake, NFT, Ownership, Sales, a socket-based Print Server, and a Slicing Interface — alongside Keycloak, RabbitMQ, Redis, and the WordPress marketplace.

Services communicate two ways. Synchronous calls go over internal REST APIs secured by JWTs with service-level scopes. Everything that can be asynchronous goes through RabbitMQ, wrapped in a three-layer processing pipeline: a pre-process layer validates the request's authenticity and permissions before any business logic runs, the process layer does the work, and an optional post-process layer handles follow-on effects (minting an NFT after a successful purchase, for example). Failed messages retry with exponential backoff and, after the final attempt, land in a dead-letter queue where they can be inspected and replayed — so a transient failure never silently loses a purchase.

Zero-trust between microservices

The most distinctive piece is the Handshake service. At boot, every microservice generates a keypair and registers its public key with Handshake. When service A calls service B, it signs the payload with its private key and attaches a Keycloak-issued server token carrying its identity. Service B looks up A's public key and verifies the signature before doing anything. A request that isn't provably from a legitimate, authorised service is rejected — even inside the private network. Compromising one box doesn't let an attacker impersonate the rest of the platform.

Identity done once, not twelve times

All human and machine identity flows through a single Keycloak realm. Users, creators, and admins are separated by role-based access control; each microservice is a Keycloak client with its own scopes; and server-to-server calls use the standard OAuth 2.0 client-credentials flow. Crucially, only one service — the auth gateway — ever talks to Keycloak directly. Every other component asks the gateway. That means authentication logic exists in exactly one place, and swapping or upgrading the identity provider is a one-service change instead of a platform-wide rewrite.

Protecting a design on its way to a stranger's garage

This is the problem that makes or breaks the business model. A creator's STL file is their product; if buyers could copy it, the marketplace would be selling each design exactly once.

• The design file never leaves the cloud. When a buyer prints, the Slicing Interface pulls the STL from S3 and runs Orca Slicer server-side — with the correct machine, process, and filament profiles for the buyer's specific printer model — producing GCode. The whole job runs asynchronously off the queue.
• Only encrypted GCode travels. The hub receives an encrypted, single-purpose GCode file and decrypts it locally at print time. The buyer gets a physical object, never a reusable digital asset.
• Rights live on-chain. Two Solidity contracts on Polygon mainnet track the lifecycle: purchasing mints a Right-to-Print (RTP) NFT; printing burns the RTP and mints a permanent Proof-of-Print (POP) record. A buyer without a printer can transfer their RTP to someone who has one — the print right is a real, tradeable asset with a tamper-proof history.

The edge: a Linux device in the customer's home

Here's a detail we're proud of: there is no custom hardware in this platform. The Hermes hub is an off-the-shelf single-board computer — what makes it a product is software. It runs Genesys OS, a version-controlled Linux image we built. Out of the box it boots into hotspot mode; the buyer connects from the mobile app, hands over Wi-Fi credentials, and the hub joins the network, registers with the cloud, and binds itself to exactly one printer — identified by hardware address, so no other device can hijack it.

On the device, the Printer Gateway Agent (PGA) speaks both dialects of the consumer 3D-printing world: Marlin-firmware printers are driven through a local OctoPrint instance's REST API, while Klipper printers get a direct WebSocket connection for real-time bidirectional control. Either way, PGA decrypts incoming jobs, feeds the printer, cleans up files after completion, and streams status, progress percentage, and estimated finish time back to the platform — which is what makes the live progress bar in the mobile app possible. A process supervisor keeps every service alive and restarts anything that crashes.

Updating a fleet you'll never touch again

From the day a hub reaches a customer, its software needs bug fixes and features for years — with no USB stick involved. The fleet is managed through the Kaa IoT platform over MQTT: each hub is a uniquely registered endpoint with its own secure token and a persistent encrypted connection, and the machinery is built to manage thousands of devices from one interface.

• OTA releases are semantically versioned and the two on-device components (the printer agent and the IoT layer) are version-locked, so the whole device moves as one unit — no partial-upgrade states.
• Endpoint filters target cohorts by version, so an update can roll out to exactly the devices running 1.0.0, and the dashboard shows how many devices matched and which have complied.
• Remote commands — trigger an update, restart services, execute maintenance scripts, pull error logs off a device — are queued with a multi-day retention window, because a hub that's offline today should still get the message when it wakes up next week.

What it actually takes to build this

Look at the disciplines this one product touches: cloud and Kubernetes engineering, backend distributed systems, message-queue design, identity and access management, web frontend, WordPress and payments (Stripe plus two mobile IAP stores plus a virtual currency), Flutter mobile, embedded Linux, printer firmware protocols, MQTT and IoT fleet management, and Solidity smart contracts.

That breadth is the real reason projects like this fail. Teams hire for the two or three disciplines they know they need and improvise the rest — and the improvised parts (usually the device fleet and the service-to-service security) are exactly where a connected platform breaks in production. The economics matter too: staffed in the US or Western Europe, a team covering this surface area costs well over a million dollars a year before it ships anything.

Lumetha engineered The Genesys end-to-end — one dedicated pod in Kathmandu covering every layer from the VPC to the smart contract to the device image, with a single accountable technical lead. That's the product: you lease the team, not the hours. A complete engineering organism on a monthly retainer — embedded in your company as your engineering department, or working white-label behind your agency's brand, which is exactly the arrangement under which this platform was built. It's proof the model works: a professional buyer of engineering services trusted this team with the entire build.

Full stack: Node.js + TypeScript · Express · React · Flutter · WordPress · PostgreSQL (RDS) · RabbitMQ · Redis · Keycloak · Socket.io · MQTT + Kaa IoT · Orca Slicer · Solidity on Polygon · AWS EKS + Karpenter · Helm + ArgoCD · Vault + External Secrets Operator · Prometheus · Grafana · Loki

You're probably not building a 3D-printing marketplace. That's the point.

No client ever needs this exact system — that's what makes it useful proof. Strip the printing away and this one project demonstrates eight capabilities we deliver individually or together, on builds of any size:

And the rigor scales down as well as up. The same team ships two-week MVPs, internal tools, and simple websites — the difference is that ours are built by people who know what the system will need if it succeeds. Complex builds prove capability; simple builds benefit from it.

Why a team in Nepal — and why this one

Kathmandu is one of the last genuinely under-priced senior engineering markets. Nepal produces strong computer-science graduates every year, but unlike the saturated outsourcing hubs, the market isn't churning through them — engineers here build careers, not six-month stints between offers. The team that built The Genesys stayed together through the entire project, and that continuity is why a system with this many moving parts stayed coherent. You are not paying a body shop's margin on a rotating cast of strangers.

The timezone works harder than people expect. Nepal (UTC+5:45) overlaps the entire European afternoon for real-time collaboration, and for North American clients it becomes an overnight cycle: brief the team at your end of day, and review finished work with your morning coffee. Your project effectively works while you sleep.

As for why Lumetha specifically — we'd rather show than claim, which is what this article is. We built everything described above, and we work as dedicated pods with one accountable technical lead: cloud, backend, mobile, embedded, and Web3 under one roof, AI-augmented delivery, and pricing published openly on our site — something almost no agency in this industry does. And you don't have to bet the project to find out: we start every engagement with a two-week paid pilot, so the only thing you risk is two weeks.

Frequently asked questions

This isn't our only build like this. Read how one Lumetha fractional CTO shipped a complete fleet-operations platform — 106k lines of TypeScript, 207 API endpoints — in under six months, or see all of our work. Ready to engage? Start at hire a dedicated development team — or, for agencies, white-label development. Unsure which model fits? Our honest comparison of engagement models.