Jakomu.
Building for customers and the team behind them.
As a Software Engineer at Jakomu, I selected the application stack and architecture and built across the public website, shared backend services, and internal AWS tools. This case study follows that work and the decisions behind it.
- Context
- Software Engineer · Jan 2026–Present
- Role
- Stack and architecture decisions, development coordination, and implementation
- Systems
- Public website, shared backend, and internal AWS workflows
- Platform
- Shared services with a separate database for each business
The context
Different businesses.
Shared software.
Jakomu needed a public website, reusable services for business applications, and internal tools. I chose the stack and architecture, coordinated development, and implemented interfaces, services with separate business databases, and AWS workflows for audits and sales research.
Business applications 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 public interfaces
to shared services.
Software Engineer at Jakomu. I selected the stack and architecture, delegated development tasks, and built across the public website, shared backend services, and internal AWS tools.
- 01
Built and maintain Jakomu's Next.js website, including service pages, reusable React components, responsive navigation, and inquiry forms.
- 02
Designed and implemented 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.
- 04
Selected the application stack and architecture, delegated development tasks, and coordinated implementation while contributing across the frontend and backend.
I worked with the founders on business requirements and coordinated development while contributing directly to the implementation. The examples here focus on my engineering work.
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, adapt to each business
React components and shared services handle common behavior. Business-specific interfaces adapt those foundations to their 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
Visitors explore the managed service and website examples through Jakomu Managed and the Showroom. Reusable React components also support business-specific interfaces.
- Jakomu Managed
- Public Showroom examples
- Reusable React components
- Business-specific 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