Behind the Build: ANKR

A developer running three projects gets asked a simple question by a lender. Where does the budget stand on the second one?

The answer takes two days. Someone opens a spreadsheet that may or may not be the current version. Someone else digs through email for the change order that was approved last month.

A third person calls the contractor about an invoice nobody can find. The number eventually arrives, and by then it has already moved.

That was the problem ANKR came to us to fix, and here is how the product took shape.

The Problem ANKR Was Built to Solve

ANKR puts it in one line: Most deals aren’t difficult; they’re disorganized.

That sentence does a lot of work. Real estate development is not confusing because the maths is hard. A pro forma is arithmetic. A draw request is paperwork. Approving an invoice takes thirty seconds once you can see the budget line it belongs to.

The difficulty comes from where all of it lives. The budget sits in a spreadsheet on someone’s laptop. The signed contract sits in a shared drive, two folders deep. The lender’s latest question sits in an email thread with eleven replies. The site photos sit on a project manager’s phone.

Nothing is missing. It is just spread across six places, and no two of them agree on what day it is.

ANKR is built for real estate owners and developers running active deals, from individual investors up to growing teams. The thing they all share is a project that has to stay organized while a dozen people touch it.

Why a Draw Request Is Harder Than It Looks

To build this product properly, we had to understand the work, not just the screens. The draw request is where the whole mess shows itself.

A draw is how a developer asks a lender to release construction funds as the project hits milestones. It sounds like filling in a form. It is closer to assembling a legal file.

A single draw package pulls together contractor invoices reconciled against the approved budget, a conditional lien waiver for every one of those invoices, documented change orders with their approvals attached, third-party inspection reports with photos from the site, a schedule of values, and the lender’s own form on top.

Then it travels. Contractors and subcontractors submit pay applications. Inspectors verify the work. Loan administrators check it against funding thresholds. On bigger deals, senior debt, mezzanine, and preferred equity partners each apply their own release rules.

Every one of those handoffs is a place where a draw stalls. Missing lien waivers are among the most common reasons a package gets held. So are outdated budget versions, change orders approved after the money moved, and spreadsheet versions that no longer match.

Manual draws can stretch weeks from submission to funding. On a project carrying interest, weeks are expensive.

This is the work ANKR had to hold. Not a filing cabinet with nicer fonts.

What the Client Brought Us

ANKR came to us with a vision and a goal, and nothing built yet.

That is our favourite kind of starting point, and also the riskiest. There was no existing product to patch, no legacy decisions to work around, and no half-finished design to inherit. There was also nothing to hide behind. Every screen, every flow, and every line of the website started as a blank page.

What they had instead was the thing you cannot buy. They knew this problem from inside the industry. They knew which parts of a deal cause arguments, which documents lenders actually ask for, and which spreadsheet everyone secretly distrusts.

Our job was to turn that knowledge into something a team could open on a Monday morning and use without a manual.

What We Built

We built ANKR’s website and its web app in 2025, designed and engineered from scratch.

The product gives every project its own workspace, and inside that workspace sit the parts of a deal that normally live apart:

Pro forma for modelling costs, financing and projected returns
Budget built by category, with draw preparation handled automatically rather than rebuilt by hand each cycle
Draws that get submitted, tracked and approved with status visible in real time
Documents stored and organized with instant search and secure sharing
Bills for paying vendors and keeping invoices and payments straight
Inspections captured from site with photos, notes, and punch lists, and importantly, offline
Lender and partner sharing so organized documents, financials, and reports go out without anyone rebuilding the package by hand.
Progress tracking from acquisition through to closeout

The offline inspections deserve a mention. Job sites are concrete boxes with poor signal, and a product that needs full bars to record progress is a product that gets used in the car park afterwards from memory. Capture had to work where the work happens.

Two Products with Two Different Jobs

The website and the app came out of the same project, and they are not the same kind of work.

The website gets a few seconds. A developer lands on it between phone calls, and in that window it has to name their problem back to them accurately enough that they recognize themselves. That is why the strongest line on the site is not a feature at all.

Most deals aren’t difficult; they’re disorganized. Somebody who has spent a week chasing a lien waiver reads that and stops scrolling.

The site also had to make trying it easy rather than brave, so a 14-day free trial and a booked demo both sit within reach of that first screen.

The app has the opposite job. Nobody arrives there needing persuasion. They arrive mid-deal, mildly stressed, looking for one number or one document. Every sentence that tries to sell them something is a sentence in the way.

So the website argues, and the app gets out of the way. Designing both meant switching between those two modes constantly, and keeping them recognisably one brand while doing it.

The Decisions That Shaped It

A few calls early on decided what the product became.

Build the whole deal, not one slice of it:

The easier product would have handled draws alone, or documents alone. Plenty of tools do. But a developer with a draw tool and a document tool and a budget spreadsheet still has three places to look, which is the problem we started with. ANKR manages the entire deal in one place rather than one piece of the process.

Tie everything to the project:

Once the budget, the invoices, and the approvals all belong to the same deal record, a change in one place shows up everywhere it matters. No reconciling. No wondering which file is current.

Make it work for one person and for twenty:

A solo investor and a growing team have the same problem at different volumes. Building only for the team would have priced out the individual. Building only for the individual would have collapsed the first time two people needed different permissions.

Cover the full lifecycle:

Acquisition through execution to closeout. A tool that handles the exciting middle and abandons you at closeout just moves the mess to the end.

Keep setup to minutes:

You create a deal and start organizing immediately. For a product replacing spreadsheets, a long setup is fatal, because the spreadsheet is always available right now.

What We Took From It

The hard part of ANKR was never the code.

The hard part was learning what a lien waiver is for, why a change order approved late causes real trouble, and what a lender needs to see before they move money.

You cannot design a draw flow from a feature list. You have to understand why the fourth step exists before you decide whether to keep it.

That is why we take on roughly ten MVPs a year rather than forty. A product like this needs someone to sit with the problem long enough to know which parts matter.

Our projects are founder-led for the same reason, so the people learning your business are the people building your software, and nothing gets lost being relayed through an account manager.

There is a second lesson in here for anyone building something similar. ANKR did not win by having more features than the tools it replaces. It won by holding the whole deal, so nobody has to carry a number from one system to another and hope they typed it correctly.

Most software problems look like missing features. More of them are missing connections.

Building something from scratch?

Want to talk about something you are building? Email info@bentadon.com or call +1 (760) 284-7782.