Kunal Ninawe

Seattle, WA
Product Engineer · Full-stack · AI-native

Kunal Ninawe

Seattle, WA

Wins

Founding engineer at OpenCFO · Apr 2026 to now

Product engineer. I ship the whole thing, and I build it for the person on the other side of the screen.

OpenCFO is an AI-native accounts payable and receivable platform. I joined as the first full-stack hire and owned the web app while the company went from 0 to 10 customers. Before that I spent four years owning partner identity at Expedia for about 100K partners. I like ambiguous problems, short feedback loops, and knowing who the user is before I open the editor.

Start from the user's day, not the ticket
Measure, then fix
Cut scope out loud
Write the ask down so the other team can ship it
21 weeks at OpenCFO
287
merged PRs
75% of the repo, in 21 weeks
87
BFF endpoints
behind 136 routes I own
0 → 3,200
tests
test suite built from nothing
40
PRs in one week
the busiest week
2.5s → 0
frozen screen time
on the busiest screen, measured not guessed

What I shipped, one card each

Each story in four parts: the context, what I did, what changed, and what I learned.

Everything · 20
For customers · 7
Speed · 4
Trust and security · 4
Team tooling · 5
For customers

Shipped three-way matching for a real distributor

~25 PRs

in one week, with the demo moved up three days

Context

Who felt it: An accounts payable clerk at a wholesale distributor who checks every bill against an order and a delivery by hand.

A prospect running on their own servers needed : each bill checked against the and the , line by line. There was no test copy of their system we could connect to, and the demo moved three days earlier.

Action

  • Read the customer call transcript and turned one of their habits, booking small price differences to a account, into a real feature: an adjustment line, kept separate from a matched line.
  • Wrote a 12-document plan the backend engineer could build against, with every open question numbered.
  • Built the matching on our server in two steps, so the bill and order show immediately and the delivery details fill in behind.
  • Cut scope out loud at standup: manual upload only, four or five realistic problem cases, lead with a clean match, and hide anything unfinished instead of faking it.

Result

The demo shipped on the new date. On the way I set up 11 realistic test bills and wrote down 8 backend behaviours nobody had documented.

Learning

I argued for a table that records every match, so finance could replay who matched what, and when. We skipped it to hit the date and worked each match out on the fly instead. I still think the record is the right end state: the first time someone asks why a line changed last week, working it out on the fly has no answer.

By the numbers

~25
pull requests in one week
12
planning docs the backend built against
11
realistic test bills for the demo
1 of 20
OpenCFO numbers come from git, GitHub, or a doc I wrote at the time. Expedia numbers are from my own records. The customer count is my own tally. Words with a dotted yellow underline explain themselves when you click them.
SKILLSET

The Magic Behind

  • One engineer for the whole surface: the screen, the API layer behind it, the deploy, and the tooling the team ships with.
  • Recent proof: an AI-native AP/AR platform taken from 0 to 10 customers as the first full-stack hire, and partner identity for about 100K Expedia partners before that. Pick a lane below to see what I actually did with each tool.

Drag or tap to switch lanes

Product

Product

Product engineering: start from the user's day, then build the smallest slice that changes it.

I find out who the screen is for before I open the editor, write the contract, ship in slices, and cut scope in the open. This is the lane I want to be hired for.

How it shows up

Page contracts

Customer calls

Scope cuts, out loud

Honest UI states

Ranked asks

Pre-demo walk

Where I have worked

Newest first. Pick a role on the timeline, then open a project or a skill for the detail behind it.

OpenCFO

Seattle, WA

Founding Full Stack Engineer

April 2026 - Present

Projects

Skills, with where I used them

Wrote a page contract before any UI: the verbs, their preconditions, permissions, the API behind each, and what the user must see to choose one.

Cut a PO match page from 5 redesigns to one 20-minute conversation, and the method now lives in the repo as a rule.

Turned an Epicor Prophet 21 customer's call transcript into a 12-doc spec and shipped three-way matching in about 25 PRs.

Demo shipped on the pulled-forward date, with scope cut in the open instead of quietly.

Parsed production Chrome traces with a Node script to find 2.4s of main-thread blocking on the bill review page.

pdf.js text layer 1.2s to 0, 226 tooltip providers to 1, PDF canvas 58MB to 8.8MB, match API 1,087ms to 738ms.

Reproduced a cross-user data leak through the browser HTTP cache and proved mid-session sign-outs were a backend design choice.

44 routes patched with a CI test that scans the source. Backend requirements doc written with the proof attached.

Designed the CLAUDE.md hierarchy, skills, hooks, review subagents, an authenticated-browser handoff for agents, and an OpenAPI spec-sync bot.

242 co-authored commits and a peak of 40 PRs merged in one week on a three-person team.

Wrote 12 backend requirement and ranked-asks documents (New / Amend / Confirm, stable IDs) and started a pre-demo readiness walk plus a weekly FE/BE sync.

The backend team shipped against the asks, and demo bugs stopped surfacing in front of customers.

PROJECT SHOWCASE

Interactive proof ofskills

Side projects with the code public. Pick one to see why I built it, what it does, what it taught me, and how it ships.

All
AI
Full Stack
Scalable Systems
Frontend
Data / ML

Project carousel

Learning Doc Builder

View live demo
Claude skill + reading app
1 / 8

Turns any topic into one short, interactive study page with a quiz at the end.

Why I built it

Long technical docs lose me halfway through. I wanted explainers built for a short attention span, where every choice about structure comes from research on how people actually remember things, not from taste. And I wanted an AI to write them in that format for me, about anything, including our own codebase.

What it does

  • A skill that researches a topic before writing, reading the real files when the topic is a codebase, then writes the doc as plain markdown.
  • A reading app that renders every doc the same way, so changing how all of them look is one stylesheet, not forty files.
  • A graded quiz of real-world scenario questions, one at a time, with an explanation for every answer and a score at the end. It is built on .
  • Dark mode, three reading widths, and a 'bionic reading' toggle that bolds the start of every word, all remembered per browser.
  • On a phone, the table of contents folds into one sticky bar that shows which section you are in.

What I learned

  • A beautiful page around wrong facts is worse than no page, so the skill researches before it writes a single heading.
  • Keeping the content as plain markdown and every visual decision in the app is what lets forty docs change their look at once.
  • An automated check on every doc's quiz catches what a human reviewer skims past.

How I built it

  • Designed the doc format first: a short header, small sections, callout boxes for the key idea and the common trap, and one quiz block at the end.
  • Built the reading app with React, Vite and Tailwind, with syntax-highlighted code and collapsible deep dives.
  • Packaged the writing process as a skill anyone can copy into their own AI setup.
  • Wrote a content checker that runs on every change and blocks a doc with a broken quiz or a missing section.

How it goes live

Every push runs the checks, builds the site, and publishes it to with GitHub Actions.

Built with

React logo

React

TypeScript logo

TypeScript

Vite

Tailwind CSS

Radix UI

React Router logo

React Router

Shiki

marked

GitHub Actions

GitHub Pages

Built with

React logo

React

TypeScript logo

TypeScript

Vite

Tailwind CSS

Radix UI

React Router logo

React Router

Shiki

marked

GitHub Actions

GitHub Pages

Engineering notes, written for the next person on the team.

I write when a decision cost us something to learn. The posts below went out on the OpenCFO engineering blog.

OpenCFO Engineering BlogSep 11, 2026 · 4 min read

We Added a BFF Layer Before Reaching for GraphQL. Here Is What Happened.

One table page was making 1 + 1 + N network calls and pulling every bill into the browser. Instead of adopting GraphQL, we put a thin per-screen Backend-for-Frontend in front of the API. It cut each screen to one call, and it caught a cross-user cache leak before it reached production.

BFF
React Router v7
SSR
Caching
API design

If you only read three lines

  1. Ask what the screen needs before asking what the graph looks like.
  2. One resource route per screen, a 30-second cache keyed by user, and a pure compute step for filter, sort, and paginate.
  3. The bug you will hit in week one: browser caching across users. Set no-store and test for it in CI.

Education and certifications

Degrees on the left, certifications on the right. Each certification links to the LinkedIn record.

Education

M.S. in Computer Engineering

New York University logo

New York University

New York, NY · May 2021

Coursework in data structures and algorithms, cloud computing, distributed systems, internet protocols, machine learning, and deep learning.


B.S. in Computer and Information Science

University of Mumbai logo

University of Mumbai

Mumbai, India · July 2019

Strong computing foundation spanning software engineering and computer science fundamentals.

Certifications

View on LinkedIn
Anthropic logo

AI Fluency: Framework & Foundations

Anthropic
Mar 2026
Credential ID: h7edwy2r4qsp

Applied Machine Learning: Algorithms

LinkedIn Learning
Mar 2021
Credential ID: AdpqsJlizw9hCYf1ePxFEWTuR6F9
Udemy logo

Face Recognition Web App in Machine Learning with Python and Flask

Udemy
Jan 2021
Credential ID: UC-7613dbd7-e71c-4a06-8e5e-edd62a7e4984
HackerRank logo

Java Basics

HackerRank
Nov 2020
Credential ID: F5FE80A1E2B5

Essential Math for Machine Learning: Python Edition

LinkedIn Learning
Jul 2020
Credential ID: AZkvNXZjR4PkWItENBAq2zhmgJX3

Introduction to Data Structures & Algorithms in Java

LinkedIn Learning
Jun 2020
Credential ID: AelsH2eBxuZFS2pjyXwrrB6Nw9Pw

WordPress: Ecommerce

LinkedIn Learning
May 2020
Credential ID: AT-x_jwYannoMRGH6e-L6wIRUwAf

Hiring a product engineer who can take a fuzzy problem from the customer call to production?

I am in Seattle and open to New York or San Francisco. The fastest way to see how I work is the Wins section at the top. The fastest way to reach me is email.

Built with Next.js and Material UI, exported statically to GitHub Pages.

Every number on this page comes from git, GitHub, or a doc written at the time. The customer count is my own tally.

Contact

Seattle, WA

ninawekunal@gmail.com