Arinze Obieze
Arinze Obieze
Technical partner to founders

I handle the tech.
You handle the sales.

I take ownership of the technical side of your product. You get more time to sell, market, and grow the business.

Talk about your productSee how I decide
  • 10+ products taken from idea to production
  • SaaS, marketplaces, education, construction, AI
  • Full ownership of the technical side
  • Product, full-stack engineering, infrastructure, AI systems
  • One person to talk to about the whole build
  • Founders who go back to selling instead of managing engineers
What you hand over

You should be selling and growing.
Not managing engineers.

Your job is to talk to customers and grow the top line. Mine is to make sure the product underneath that growth does not break, does not leak data, and does not ship a feature that demos well and falls over in production.

You stop being the project manager

When the UseMoos founder said their enterprise customers needed to know the AI would never surface a document someone was not allowed to see, I did not ask for a ticket. I designed the permission check to run before the retrieval query, built tenant isolation at the query layer, and shipped it.

By week three he was demoing it to 25 enterprise leads, without once being pulled into a security review.

Your calendar is not the bottleneck

I run my own sprints and surface blockers with a recommendation attached. When Kota AI's retrieval quality dropped after a vector database migration, the CI-gated eval harness caught it before the change could merge, and the founder heard about it from me with the fix already in hand.

The regression never reached production. His customers never saw a worse answer.

You ship while you sleep

On roomfind.ie the search pipeline, the filtering logic, and the booking flow were handled end to end. The founder's involvement in the final stretch was reviewing the live link and giving feedback.

He spent that stretch on acquisition and physical outreach, and launched with listings already on the platform.

I stay after the launch

A bug in week one is still mine. I have stayed with products through their first 5,000+ daily active users and through infrastructure migrations with zero downtime.

Two years on, those products are still running.

That is what focusing on growth actually looks like.

The toolkit

Where I am useful

A technology list shows familiarity. What follows is what I actually take off your hands, and the judgment that comes with it.

AI

Most AI features fail on retrieval and permissions, not on the model. That is where I work.

The hard part is usually deciding what the model is allowed to know. Retrieval that returns semantically related but irrelevant documents looks like a model problem and almost never is.

  • RAG pipelines
  • Hybrid retrieval
  • Vector databases
  • Embeddings & reranking
  • Agentic tool-calling
  • MCP
  • AI evaluation
  • LLM-as-judge
  • Golden datasets
  • Multi-tenant retrieval
  • Guardrails & permissions
  • Latency & token cost

Product Judgment

Turning an unclear idea into a scope someone can build.

Most of this happens before any code is written. What the product actually needs, what gets cut, and which version answers the question you are really asking.

  • Product architecture
  • MVP scoping
  • Requirements discovery
  • Technical tradeoffs
  • Phased delivery
  • System integration

Frontend / UX

Non-technical users judge a product by whether it makes them feel in control.

They do not care about the stack. They care about whether the thing they are responsible for looks like it is going to work, which is a design and interaction problem as much as an engineering one.

  • React
  • Next.js
  • TypeScript
  • Tailwind CSS
  • UX design
  • Design systems
  • Interaction design
  • Accessibility
  • Figma to code

Backend & Data

Systems that hold up as you grow, and that you are not paged about at 2am.

Sized to the traffic you actually have, with the room to grow when growth arrives. The failure modes that matter are the ones nobody wrote down.

  • Python
  • FastAPI
  • Node.js
  • PostgreSQL
  • MongoDB
  • Redis
  • Supabase
  • Auth & RBAC
  • Background jobs & queues
  • Data modelling
  • Payments

Infrastructure

Deployed, monitored, and running without a team to babysit it.

You should not need to hire an engineer to keep the thing you already paid for online.

  • AWS
  • GCP
  • Vercel
  • Cloudflare
  • Docker
  • CI/CD
  • Observability
  • Zero-downtime migrations
  • Backups & recovery
  • Secrets management
  • Cost management

Selected work

Products I owned technically, from the first scoping conversation through to production.

01Case study

usemoos

An enterprise knowledge layer that only shows an employee what they're actually allowed to see.

Permission-Scoped RetrievalMulti-TenantDesign SystemEval Pipeline
Read case studyLive site

What it took

  • Permission check runs before the retrieval query, so an unauthorized document never enters the context window at all
  • Tenant isolation enforced at the query layer, not in UI or application logic sitting on top of a shared query
  • Built solo end to end: design system, backend, and infrastructure migrations with no production downtime
02Case study

RoomFind

A rental marketplace where the compatibility score decides who is allowed to see a listing at all.

Compatibility as AuthorizationCold-Start RankingPersonalized Feed CachingFail-Closed Security
Read case studyLive site

What it took

  • The match score gates visibility and contact, so cold contact from a bad fit is impossible by design rather than moderated
  • Scoring weights change with the listing type, from 35 percent lifestyle harmony in a shared flat to zero in a whole apartment
  • Feeds are precomputed and invalidated by version counter, so one profile edit orphans every derived view atomically
03Case study

Kota AI

Trainable AI customer support inside Bunloop.

Hybrid RAGRetrievalRealtimeEval Harness
Read case studyLive site

What it took

  • Hybrid vector + keyword retrieval fused with Reciprocal Rank Fusion, reranking only when results are genuinely ambiguous
  • CI-gated eval harness scores recall@k, MRR, and handoff correctness on every change, exiting non-zero on regression
  • Hands off to a human live in the same inbox when confidence is low, instead of guessing in front of an end user
04Case study

TunnelAlpha

A backtesting engine that refuses to tell a trader a number it can't back up.

Natural Language ExtractionBacktesting EngineMarket DataResult Validation
Read case studyLive site

What it took

  • Zero false encodes across 63 live classifications, measured on 21 real trader strategy descriptions
  • 73-case regression suite caught a same-bar look-ahead in trailing stop logic and a level-vs-crossing entry bug
  • Deflated Sharpe Ratio and a held-out final 30% of candles, so in-sample and out-of-sample never blend

Client work

Platforms and products shipped for clients across real estate, education, and SaaS.

Ishelter

Fullstack Developer09/2023 - 12/2025

Multi-role construction management CRM with geospatial features.

CRMGoogle MapsReact

Waccps.org

Fullstack Developer06/2025 - 08/2025

Education management platform for West African College of Clinical Physiology Sciences with integrated payment processing.

EdTechPaymentsRole-based auth

Everything Shelter

Fullstack Developer2024

Construction management and real estate marketing firm.

Real EstateSEOLead gen

Ditcal.com

Fullstack Engineer06/2023 - 09/2023

Team scheduling platform charging one flat rate per team instead of per seat, an alternative to per-user tools like Calendly.

CalendarAPISaaS

Process

From first message to shipped product, in order.

Founders who have been burned by developers usually describe the same thing: slow replies, work that drifted from what was agreed, and no way to tell whether the project was on track until it was late. Most of that comes from decisions being made verbally and never written down. This is how I avoid it.

  1. Step 01

    Intro call

    scope: unknown → understood

    I want to understand the business before the product. Who your customers are, what you are trying to learn from this build, and where you want the company to be. We also agree on one channel so decisions take hours instead of days.

  2. Step 02

    Scoping doc

    scope: understood → written

    The conversation becomes a written scope: what gets built, what is explicitly out, and what done means. This is where I argue for cutting things, so that what remains is the part that actually moves the product forward.

  3. Step 03

    Architecture & roadmap

    plan: written → sequenced

    The technical approach gets chosen against the users you have, not the users you hope for. Phasing matters here: earlier phases can often generate revenue that funds the later ones, which beats paying for everything upfront.

  4. Step 04

    Contract

    terms: agreed → binding

    The scoping doc gets formalized, including how out-of-scope requests are handled. Scope creep is a pricing problem disguised as a communication problem, so it gets answered in writing before the project starts.

  5. Step 05

    Build sprints

    product: spec → running code

    Short, visible build cycles instead of disappearing between milestones. You see the product as it is built, so you can redirect early instead of discovering a mismatch at the end.

  6. Step 06

    QA

    build: assumed correct → verified

    Everything is tested against the scoping doc rather than against whether it looks like it works. The edge cases that reach real users are the ones nobody wrote down, so this is checked against the written scope.

  7. Step 07

    Post-launch support

    product: shipped → stabilized

    I stay through stabilization. A bug found in week one is mine to fix. You should not have to chase the person who built the thing, and you should not need to hire an engineer to keep it running.

Writing

Arguments about scope, cost, and technical decisions, worked out from products I have actually built.

01

Does Your Workflow Actually Need an AI Agent?

Thoughts
02

I Move Fast On Infrastructure And Slow On Architecture.

Thoughts & Opinions
03

Why traction doesn’t mean product-market fit

Career & Clients
See all articles

What people say

From founders and teams who handed me the technical side and went back to running their business.

Arinze built usemoos end to end, from the design system to the permission-scoped retrieval to the infrastructure, and stayed accountable well past launch. He treats the eval numbers as seriously as the demo, which is exactly what you want in someone building an AI product you have to trust.

Ifeanyi Daniel
Ifeanyi Daniel
Founder, usemoos

Tell me what you're building

Two questions, because the answers change the advice: what you are building, and what stage it is at today. If I think the work is smaller than you expect, or that something is not worth building yet, I will say so early.

Book a free 30 minute callBring the problem, leave with a direction
Emailarinze@arinze.dev