Musawir Raji's Work | ContraWork by Musawir RajiMusawir Raji
Full Stack AI Engineer · I take AI built apps to production
A founder I worked with insisted that my name be added to her app as recognition for the work I did. That meant more to me than she probably knows.
Meet Readiary, a reading journal mobile and web app I built for a founder.
It started with an idea and a vision. No detailed PRD, no fully mapped-out product requirements. Just a founder who knew what she wanted to bring to life.
I took that vision and turned it into a working product. I designed the UI, planned the backend architecture, made the technical decisions, built the app, and shipped it to both the App Store and Google Play Store.
Today, it’s a product people can actually use.
What makes this even more special is that the founder didn’t just appreciate the work. She made me her CTO. Every major technical decision now goes through me.
And honestly, it got me thinking.
These days, a lot of the best work developers do stays behind closed doors. NDAs, agency agreements, and client confidentiality mean you sometimes can’t even talk about a product you spent months building.
And that’s understandable. Business is business.
But sometimes, I wonder if we’ve made it too difficult for developers to show the work they’re genuinely proud of.
Anyway, I’m grateful this is one of those projects I can actually share.
If you’re a founder, whether you’re building in YC, SF, or anywhere else, and you need a developer who will care about your product almost as much as you do, I’d love to talk.
I like getting deep into products, challenging ideas, making technical decisions, and taking things from just an idea to something people can use.
I also use AI heavily in my workflow to move faster without compromising the quality of what I build.
My DMs are open. I’m ready for the next interesting project. Four months ago a founder hired me for a $120 Supabase job. Today her app is live on the App Store and Google Play.
She had a reading tracker she’d built with AI tools. It worked on the web, the backend was written and waiting, and she needed someone to wire it up, deploy it and make sure a reader’s library synced across phone and laptop. Setup, not building. A small, clean job.
I did that one properly, with a short note explaining how it all fits together so she could manage it after. Then she came back for the next phase, and the next.
When she wanted a mobile app, I didn’t start over. I kept her backend and built iOS and Android on top of it, so the same accounts and the same library work everywhere. I wired in Stripe and RevenueCat so a subscription works across web and phone, and took it through both store reviews. App Store in August, Google Play in September.
Last month we shipped book clubs: one book read together in parts, with discussions that stay locked until you reach that part.
Small first jobs are how I’d rather start too. An AI guide grounded in 56 texts of conscience. It quotes only what it finds, shows only the sources it used, and finds the right one 94% of the time.
The brief
VoxAnima is a conversational guide for people facing a moral choice at work: the moment you see something wrong and have to decide whether to keep going. It speaks in the voice of its founder, an activist and author with 35 years in the work. It draws on a fixed library of nonviolence and wisdom literature: Gandhi, the Gospels, the Hebrew Bible, the Qur'an, the Dhammapada, Tolstoy, the Quakers, the Stoics and more.
One rule mattered more than anything else. Every claim had to come from a passage the system actually found, and the source line under each answer had to be true.
What I built
A searchable library of 56 texts, split into 1,600+ passages, stored in Postgres with pgvector and searched by meaning on every question.
Chunking that respects the texts. Scripture is split by whole verses, so no passage cuts a verse in half or crosses a chapter. Each passage carries its own reference, like Isaiah 58:1-14, so the answer can say exactly where a line came from.
A search cutoff measured, not guessed. The original spec's threshold was tuned for a different embedding model and returned nothing. I measured the real score range and set the cutoff from the data.
A balance rule. Scripture is about 60% of the library, so it used to crowd out every other voice. Each answer now takes at most 2 passages from any one source, which leaves room for Woolman, Tolstoy or the Buddha to speak.
Sources you can trust. The model numbers each passage it uses. The app shows a source line only for passages the answer actually drew on. A passage that was found but not used gets no byline.
A test set for search. 34 real questions with known answers, run before and after every change. The right source lands in the top 5 for 94% of them.
Fail loudly, never silently. When the database went down in production, the app had kept answering with no sources and nobody could tell. I made failures visible, added a daily health check, and the test suite now refuses to pass against a dead backend.
Results
94% of test questions find the right source in the top 5 (MRR 0.78)
Only cited passages get a byline: in the cover's live example, 5 passages were found, 3 were used, and 2 got no byline
The founder's voice comes from his own recorded answers, held as a reference set the model writes against
Stack
Next.js · Supabase (Postgres + pgvector) · Voyage embeddings · Claude via the Vercel AI SDK · Vercel A website, realtor app, office desk and developer portal on one database. Every sale is checked against its receipt, so no plot is ever sold twice.
The client. A realtor network in Ibadan. Realtors join through someone already in the network and sell estates plot by plot for developers. Before this, the work ran on a WordPress portal, WhatsApp and spreadsheets.
The problem.
Payment receipts were checked by hand on WhatsApp, and some were lost, reused or faked.
Nothing stopped two realtors from selling the same plot.
Who brought in whom could be changed quietly.
Developers couldn’t see what was selling.
What I built. One platform with four parts:
Public website: live estates showing plots left, and a clear path to join or list an estate.
Realtor app (phone-first): your circle of people, estates to sell with a live plot map, and a receipt upload that holds the plot the moment it’s sent.
Office: one Desk for every decision, with a recommended answer for each receipt (amount short, wrong sender, reference already used). Estates, the network tree, members, sales and a full audit log.
Developer portal: developers watch their own plots sell, without seeing the network.
How.
I started with research: a teardown of the competitor, what each user needs, and the hard problems written down before any code.
Then design: three concepts, sign-off, and a sample of every screen before building it.
The rules live in the database, not the screens. A plot becomes sold only when its receipt is approved, a plot can’t have two live sales, and an upline only changes with a written reason. The audit log can’t be edited.
Over 100 automated security checks prove each person only sees what they should.
Outcome. A network that runs on proof instead of screenshots in a chat, and an office that clears a day’s receipts from one screen.