Jakomu.
Building for customers and the team behind them.
At Jakomu, I build customer-facing interfaces, shared backend services, and internal tools for researching prospective clients. This case study follows my contribution across those three areas.
The backend work shown here covers implementation and testing. Production tenant operation is outside the scope of this case study.
- Context
- Software Engineer · Jan 2026–Present
- Role
- Full-stack engineering within Jakomu's product team
- Systems
- Client websites, shared backend, and internal sales research
- Platform
- Shared services with a separate database for each business
The context
Different businesses.
Shared software.
Jakomu needed to explain its managed website service, adapt software to different client workflows, and organize business data for sales research. I worked across those needs: public and client interfaces, shared services with separate business databases, and a lead pipeline that tracks sources and export readiness.
Clients need different workflows while many interface and service behaviors are shared.
Customer experiences, shared backend services, and internal operations require different access and data boundaries.
Provider terms and outreach rules limit which lead data can be stored, reused, or acted on.
My contribution
From client interfaces
to shared services.
Software Engineer on Jakomu's product team. I build and maintain client interfaces, shared backend services, AWS infrastructure, and internal data workflows.
- 01
Build and maintain Jakomu Managed, reusable React components, and client interfaces in collaboration with the product team.
- 02
Implemented and maintain the shared NestJS/PostgreSQL platform, tenant routing, AWS deployment configuration, and repository verification.
- 03
Implemented and maintain the AWS-first sourcing, enrichment, scoring, provenance, DNC/readiness, and CRM-ready export workflow.
This work sits within the Jakomu team's broader product and delivery effort. The examples here focus on my engineering contribution.
The decisions
Where to reuse.
Where to adapt.
01Share service logic, separate business data
A central registry identifies each business, and tenant routing directs requests to its own PostgreSQL database. Common service logic can be reused while business records stay separate.
02Reuse shared behavior, tailor each client experience
React components and shared services handle common behavior. Client interfaces adapt those foundations to each business's workflows and requirements.
03Separate lead intelligence from outreach permission
A researched business record does not establish permission to contact it. The pipeline tracks where data came from, do-not-call status, and export rules so outreach readiness can be checked separately.
05 /The experience
Website examples
you can explore.
The public Website Lab shows how reusable components can support different businesses. Visitors can explore website examples and review the direction for each one.
Architecture
Customer products.
Platform and operations.
Select a layer to see its responsibility and the components involved.
Product · Managed delivery
Customers explore the managed service and website examples through Jakomu Managed and the Showroom. Reusable React components also support tailored client interfaces.
- Jakomu Managed
- Public Showroom examples
- Reusable React components
- Tailored client interfaces
Platform · Multi-tenant services
Each business has a separate PostgreSQL database. A central registry resolves tenant context so shared NestJS services can route requests to the appropriate data.
- Shared NestJS services
- Central business registry
- Tenant routing
- Per-business PostgreSQL
Operations · Lead intelligence
The pipeline turns licensed business profiles and market context into scored CRM records. It tracks each source and checks do-not-call status and outreach readiness through export.
- Licensed stored profiles
- Aggregate market context
- Scoring + provenance
- DNC/readiness + CRM-ready export
Interfaces, shared services, and data workflows are verified through their own test and release paths.
Verification
Check each layer.
Check the handoffs.
Interface tests, service checks, and data controls address different failure modes across the product, platform, and internal tools.
Repository lint, build, unit, coverage, accessibility, and Playwright gates cover the relevant application and service packages.
Browser, API, and data-workflow checks cover the product, platform, and operations layers.
Source lineage, DNC status, and outreach-readiness checks are validated independently from CRM export.
Supporting material
Public product
The public site explains Jakomu's managed website service and gives customers product examples to explore.
Open Jakomu (opens in a new tab)Multi-tenant platform
The implemented and tested backend resolves tenant context through a central registry and routes requests to isolated business databases.
Lead intelligence
The internal pipeline prepares sourced, scored CRM records while retaining source lineage and checking DNC status and outreach readiness.
08 /What this enables
The public Website Lab gives prospective clients working examples to explore. My backend contribution includes implemented and tested tenant routing, alongside an internal pipeline that prepares sourced business records for CRM export with outreach-readiness checks.
Public Jakomu and Website Lab examples, tenant-routing architecture, and repository test and build checks.
Let's discuss the work