Martins Ngene · Full Stack Engineer
I build systems
that scale
seamlessly.
I'm a full-stack engineer working at the intersection of product engineering, API design, and automation architecture. I don't just build features — I build systems that remove themselves from the critical path.
Technical Skills
TypeScript is my primary language across the full stack. I write strongly-typed, readable code with proper interfaces, generics, and null handling built in from the start — codethat's built to be understood by the next engineer in the future, not just to compile today. I work in JavaScript daily, applying modern patterns like async/await, destructuring, and functional array methods.
I build production-grade interfaces with Vue.js, React and Next.js, making deliberate decisions about rendering strategies — server-side, static, or client-side — based on performance requirements, not convention. I manage complex application state with Redux Toolkit, and build consistent, accessible UIs with Tailwind CSS and Shadcn.
Node.js is my backend foundation — Express for simplicity, NestJS when a codebase needs modularity and the team needs guardrails. I design REST APIs with failure as a first-class concern: graceful degradation, intelligent retry logic, rate limiting, and logging clear enough to debug under pressure.
I treat GraphQL as a contract, not just a query format. I write queries and mutations from scratch, design action handlers, configure webhook triggers, and manage Hasura permissions across environments. I know the difference between a slow query and a missing index.
The most underrated engineering skill is recognising when a complex manual process is really just an unwritten program. I've engineered end-to-end pipelines that eliminated 25 hours of weekly manual work by modelling business logic precisely enough to automate it completely.
I think about data models before I think about code — because the shape of the data determines the complexity of everything built above it. PostgreSQL is my daily driver: writing queries, designing schemas, managing remote connections over SSH tunnels, debugging lock contention and slow joins.
Git, Docker, and CI/CD are tools I use as craft, not checkboxes. I've configured SSH key authentication, containerised local development environments, debugged ECONNREFUSED errors at the network layer, and written scripts that eliminate repetitive deployment tasks. A clear deployment pipeline saves days.
Claude, Cursor, and v0 are tools I use to eliminate toil, not to follow trends. I've built prompt-driven pipelines, wired LLMs into event-driven workflows that replace hours of manual work, and used AI-assisted development to ship faster without cutting corners. The best automation is the one nobody notices.
I document complex systems for both technical and non-technical stakeholders — migration guides, API documentation, workflow READMEs. I hold an EF C2 English Certificate and an IELTS Academic score of 7.5. I write with the assumption that the next reader won't be able to ask me a follow-up question.
Work Experience
Full Stack Engineer
Ventura TRAVEL · Remote
- Engineered an invoice validation pipeline that eliminated 25 hours of manual work weekly — modelled the business logic precisely enough to automate it completely end-to-end
- Led the full migration of automation workflows from Make.com to n8n, converting black-box scenario blueprints into typed, version-controlled TypeScript — making implicit logic explicit for the first time
- Collaborated on building an internal CRM to replace HubSpot, reducing tooling costs while producing a better fit for actual team workflows
- Built event-driven reservation and flight processing systems using Hasura GraphQL, webhooks, and async TypeScript handlers
Senior Full Stack Engineer
Software Dynamics Labs · Remote
- Built and optimised full-stack applications with deliberate decisions about SSR, SSG, and CSR rendering strategies based on real performance requirements
- Refactored legacy codebases — replaced arrow code with early returns, implicit logic with explicit TypeScript types, and "it works, don't touch it" with code the team could extend
- Contributed to codebase quality through systematic refactoring, test coverage, and documentation for distributed teams across time zones
Senior Software Engineer (Frontend)
oLab · Remote
- Built UI components and features close to the user in a fast-moving environment where adaptability was a daily requirement
- Developed React components with clean state management and API integration patterns that the team could extend without fear
Software Engineer (Frontend)
Kleekit · Hybrid
- Delivered client-facing web projects across multiple industries under tight delivery timelines — built the habit of shipping clean code even when the environment was ambiguous
- Worked with design handoffs, browser compatibility requirements, and multi-stakeholder feedback cycles
Engineering Philosophy
My first serious work was in the browser. React, Next.js, TypeScript — building interfaces that had to feel right, load fast, and not break when users did unexpected things.
I learned how to choose between server-side rendering and static generation not from tutorials, but from shipping features that performed poorly until I made the right call.
But the more I built on the frontend, the more I wanted to understand what was happening behind it. What was the API actually doing? Why was this query slow? That curiosity pulled me deeper.
// Choose based on data freshness, not convention
const getStrategy = (page: PageConfig) => {
if (page.dataChanges === 'realtime') return 'SSR'
if (page.dataChanges === 'daily') return 'ISR'
return 'SSG' // default: build-time, fastest
}I moved into Node.js and never looked back. Express when the problem was simple. NestJS when the codebase needed structure.
Early in my backend work, I inherited automation systems built on assumptions that no longer held. I refactored them — not just to make them work, but to make them understandable.
That's when I understood that reliability isn't about avoiding failure — it's about making failure visible and recoverable.
// Early returns: fail loudly, fail fast
export const validateInvoice = (inv: Invoice): Result => {
if (!inv.id) return err('Invoice missing ID')
if (inv.currency !== inv.booking.currency)
return err('Currency mismatch')
if (inv.total <= 0) return err('Invalid total')
return ok(inv as ValidInvoice)
}Most engineers treat GraphQL as a query format. I treat it as a contract. In production, I worked directly with Hasura — writing action handlers, configuring webhook triggers, managing permissions.
I know the difference between a slow query and a missing index. I know how to design a mutation that fails clearly rather than silently corrupting state.
Real-time data synchronization, event-driven pipelines, complex data processing — these were the systems the business ran on, and they had to work.
export const notifyPaxChange = async (
data: PaxChangePayload
) => {
return hasuraFetch({
mutation: `mutation HandlePaxFlight($data: jsonb!) {
handlePaxFlightSpecialRequest(data: $data) {
error
message
}
}`,
variables: { data }
})
}The most underrated engineering skill isn't writing complex code — it's recognising when a complex manual process is really just an unwritten program.
I've engineered end-to-end data processing pipelines that reduced 25 hours of weekly manual operations to zero — by modelling the business logic precisely enough to automate it completely.
The goal was never to replace people — it was to give them their attention back.
// A process running on human attention
// is a system waiting to be built
const pipeline = new Pipeline()
.step('fetch', fetchInvoices)
.step('validate', validateWithAI)
.step('match', matchToBookings)
.step('route', routeExceptions)
.onError(notifyOpsTeam)
.run() // replaces 25hrs/weekDatabases are where optimism goes to die — and where good engineering earns its keep. I work with PostgreSQL daily: writing queries, designing schemas, managing remote connections.
I've connected to databases over SSH tunnels, configured SSL, and managed credentials across environments without ever hardcoding a secret.
I think about data models before I think about code. The shape of the data determines the complexity of everything above it.
-- Design once, maintain forever
CREATE TABLE reservations (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
departure_id UUID NOT NULL REFERENCES departures(id),
currency TEXT NOT NULL CHECK(currency ~ '^[A-Z]{3}$'),
total NUMERIC(12,2) NOT NULL CHECK(total > 0),
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);I'm not chasing a stack. I'm building the instinct to look at a broken system — whether it's a slow query, a fragile workflow, or a manual process costing hours every week — and see the path through it clearly.
Every project I've shipped has made something faster, cheaper, or more reliable for the people depending on it. That's the standard I hold myself to.
That's what I'm here to keep doing.
const principles = {
code: 'Write it to be understood, not just to run',
data: 'Model first, implement second',
systems: 'If a human does it repeatedly, automate it',
failure: 'Make it visible, make it recoverable',
quality: 'Fast, cheap, reliable — pick all three',
} as constLet's build
something
real.
I'm open to senior engineering roles, interesting consulting work, and conversations worth having.
martinsngene.dev@gmail.com