Key Takeaways:
Two years ago, building software end to end meant a whole team working for at least a month: a project manager to run the process, a designer for prototypes, engineers and developers for implementation. That structure existed because the work couldn’t be done any other way. Now, with AI-first development, a single person working with AI agents can go from a prompt to a working artifact over a weekend, and if you run a valuation firm or a brokerage, that has probably changed what you think a custom system should cost.
However, making a working artifact into the real software that closes business gaps still takes someone with real estate expertise who understands both how the work is supposed to happen and how AI itself works, including the nuances where it is most likely to fail or hallucinate. In AI-first software delivery, this is the core difference between “software that works” and “software that works well, is safe, secure, and holds the data the business depends on.”
Ascendix Technologies recently built an AI-powered platform for a commercial appraisal firm, working with the principles of AI-first software delivery from the start. The developed platform is a broad internal business system, closer to a lightweight CRM than to a single-purpose tool: accounts, contacts and clients, properties, appraisal jobs, market data, comparable sales and leases, tax comps, land comps, and the reporting workflows that turn all of it into an appraisal. For a closer look at how agents behave inside a live product, see our blog post on agentic AI development in real estate.
The AI-first software development process is still ongoing, and for this reason I’m sharing it as a lessons piece rather than a results story. What we learned is that the gap between a demo and software that delivers business results is wider than any AI enthusiast is ready to admit, and that AI, even though it is “AI-first software development,” is actually the second most important thing.
In this article, I’ll share what AI-first software delivery means in Ascendix’s work process, where it can – and shouldn’t be applied, and what things, except AI, defined our success in this development case.
Ascendix team are experts in both AI and real estate. Our knowledge lets us optimize the processes with AI while maintaining high quality of development.
AI-first software delivery is an approach where AI agents generate most of the code and early prototypes while engineers concentrate on architecture, domain judgment, and production readiness. The key principle in AI-first software delivery is to delegate the repetitive and highly manual development processes to AI, but entrust key decisions on safety, security, data processing, and architecture to human expertise.
Here are some things that did not change with AI-first software delivery: deciding what the system should do, knowing when a generated answer was wrong, and everything that happens between “it works on my machine” and “the people who depend on this on a Tuesday morning.”
An AI agent has read more about commercial real estate than anyone on our team ever will. It can define a capitalization rate, explain the sales comparison approach, and describe what belongs in a narrative appraisal report.
However, as soon as you ask it to build the data model behind those things, you are likely to get something that looks professional but actually isn’t.
Essentially, it happens because AI does not have any access to internal data and has no understanding of how exactly processes run in each and every real estate appraisal firm. This data is simply not public, so using generic Claude or ChatGPT will result in generic answers that may seem right, but in the end, will be completely detached from the industry’s best practices.
Here is what that looks like in practice. Ask for a “comparables” table and you’ll get one table with property, price, date, and distance. It looks reasonable on paper, but it’s wrong, because a comparable isn’t one thing – but four that are different.
A comparable sale is a similar property that was sold. Of the four types, it’s the strongest proof of what the property you’re valuing is worth, since it shows the real price someone actually paid. But markets move, so that proof gets weaker with every month that passes after the deal closes.
A comparable lease is different: nobody bought anything, but a tenant rented a similar space. The rent number alone tells you almost nothing, because every lease comes with terms that change the real price: scheduled rent increases, discounts and incentives, allowances for fitting out the space, and who covers which operating costs. You have to adjust for all of that before the lease says anything useful about value.
Then there’s the tax comp — the value a government assessor assigned to a similar property for tax purposes. Tax records are public and official, which makes them tempting to rely on. However, assessors update their numbers on a fixed schedule, sometimes years apart, so a tax comp tells you what the assessor thought just back then, not now.
Finally, a land comp is a sale of empty land. Here, you compare prices per acre or per unit that could be built, and what drives the price is what the buyer is allowed to build there (zoning and permits), not anything standing on the site.
An appraiser weighs all these aspects and gets challenged on them differently. When you collapse them into one table, you’ll have built something that stores data but can’t support the reasoning the data exists for. The model doesn’t know how to object, because objecting requires an opinion about how appraisal works. AI is not taught to challenge things, only to support your opinion. It has the world’s knowledge and no organic point of view about which part applies here.
It was just a quick example of what may go wrong when you apply AI without understanding its knowledge limitations. In a similar way, AI-first software development, when done with generic AI tools, can easily mess up and create a beautiful system that does nothing for business needs. Therefore, the key to success in AI-assisted software development is industry understanding, deep domain expertise, and meticulous oversight from human AI professionals who know what a valuation flow, a comp search, or a property record must look like before they build it.
In AI-assisted software development, everyone’s instinct right now is to solve every messy problem with AI. At the beginning, we did that as well, until production reality pushed back. The problem is that the model can answer the same question differently each time, and a business system can’t run on “usually right.” So we flipped the approach: let AI build the standardized process, and let plain, predictable code run it.
Let’s talk about a real example: document extraction. When the source documents are genuinely varied (different formats, different layouts, whatever a client has accumulated over fifteen years), an AI model is the best option, because it differentiates the input and can sort it out. When the input is stable and structured, a static parser beats it on nearly every axis that matters in production: it costs a fraction as much per document, it returns the same answer every time, it fails loudly instead of confidently, and you can write a test for it.
The key insight we got is that AI is often best used to build a standardized process rather than to execute one. We used agents heavily to work out the extraction rules, find the edge cases, and write the parser. Then the parser runs, deterministically, forever. The intelligence went into constructing a tool and making it as business issue-oriented and comprehensive as possible.
After a demo with polished input and production-ready data, it may be extremely disappointing to reveal that one working feature does not equal high-quality working software. Inputs get messy, users get lazy, and the system stops working altogether at the most inconvenient time. An appraiser pastes a value with a currency symbol in it. A job gets reassigned mid-report. Somebody uploads a 90-megabyte PDF over hotel Wi-Fi and closes the laptop. Two people edit the same comp set within a few seconds of each other. All these are just usual things that happen daily, and AI-first software delivery must account for them as well.
The quality of AI-assisted software development is checked in daily work: what happens under concurrent load, how long a comp search takes when the market-data table is large rather than seeded, where the thing is hosted and what happens when that host has a bad night, what the error state says to a user who can’t fix it themselves, who gets alerted, what’s logged, what’s backed up, who is allowed to see which client’s file, and whether the people who have to use it accept it.
So, to sum up: a demo proves the feature works once; production means it keeps working when things go wrong. AI won’t reveal its own failures, so a human expert has to, and in AI-first software delivery that is a crucial point.
Agents and people work at different speeds. That mismatch in everyday life becomes a whole management problem in AI-first software delivery.
An agent produces a large amount of plausible work very quickly. A person reviews it much more slowly. Left alone, that gap fills with code nobody has really read, which is a debt you take on without noticing.
The specs became the code. The artifact that mattered most stopped being any particular file and became the specification, precise enough that an agent could implement it and a person could check the result against something other than their memory of a meeting. Vague specs used to produce slow projects. Now they produce fast wrong ones, which is worse.
Multi-agent workflows still need human checkpoints. Agents can review each other’s output, and that catches a real class of mistakes. However, it does not catch a data model that misunderstands the appraisal process, because every agent in the chain shares the same misunderstanding. The checkpoints have to include someone who knows the domain.
Somebody has to have an opinion about the interface. A model can produce a screen that satisfies every requirement and is still irritating to use for the fortieth time that day. It has no opinion about whether a workflow feels heavy, because it has never had to do the work forty times. Our judgments about intuitiveness were the least automatable part of the project, and adoption depends on them more than on anything under the hood.
Custom software means you own it, which is obvious, but people rarely know what it means in practice.
Here’s how we felt it. Because AI made building cheap and fast, the platform kept growing with more entities, screens, and workflows. And every piece we added is something the client will own: the maintenance, the support call when an appraiser can’t submit a report an hour before a deadline, the uptime, the security updates, the roadmap. Custom software works when it works; when it doesn’t, it is you who has to fix it.
AI-assisted software development dramatically cuts the cost of version one and barely changes the cost of year ten. Cheap generation makes it easy to end up with more systems than you are able to maintain.
This project made us more respectful of mature platforms. One that has survived a decade of other people’s edge cases carries a lot of quiet correctness you’d otherwise rediscover one bug at a time. Custom is the right answer when your process is genuinely different; it’s an expensive one when you’re rebuilding something ordinary just because rebuilding felt cheap.
This is actually the key point of this article about AI-first software delivery and the main message I want to deliver.
Because our team already understood appraisal workflows, comps, valuation methodology, property data, and reporting, we could make informed assumptions instead of asking about everything. Discovery got shorter because we had a head start with deep valuation knowledge, so we spent it on the questions specific to our client’s processes rather than the ones every appraisal firm answers the same way.
Some other things we learned were the following.
It is better to use the right-sized limited data pool than a massive block of generic data. A common failure is to model everything a domain could contain, producing a bloated schema where most fields are empty, and users can’t find what matters. Knowing which fields appraisers actually reach for, and which ones exist only in textbooks, is the difference between a system people use and a system people work around.
The features that drive adoption are rarely the impressive ones shown during a demo. More often, they are generalized and intuitive site features common for software tools. What appraisers really cared about in this project was entering data right on site, from a phone, instead of retyping their notes into a desktop form. It removed an annoying manual chore from the end of a real workday – and to know which chore to remove, you have to know the job.
If you’re choosing an AI-first software delivery partner rather than designing the process yourself, most of the above converts into questions. These are the ones I’d ask before getting a demo and signing a contract.
Last one, which tells you the most: what would they talk you out of? A partner who agrees with everything in a scoping call is optimizing to win the work, not to build the thing.
Weighing a custom build? Book a free AI consultation with Ascendix. We’ll tell you where AI-first software delivery helps, where it doesn’t, and what you’d own after launch.
Building software has never been easier than with AI-first software delivery. But building good, production-ready software that people actually adopt has not gotten easier, and I don’t think it’s going to.
Working in AI-first software development changed our delivery, and I’d make the same call again. We moved faster with a smaller team, explored more options before committing, and spent a much larger share of the project on decisions rather than typing.
What made it work, though, was that we already knew what an appraisal job, a comp set, and a valuation workflow are supposed to look like before we asked anything to build one. The AI supplied speed – but the domain knowledge supplied direction. Take the second one away and you get a fast, confident, well-structured system that solves a problem nobody in the building actually has.
The platform we’ve described isn’t in production yet, so I’m not going to tell you what it achieved. When it is, that’s a different article.
AI-first software delivery is an approach where AI agents generate most of the code and early prototypes, while engineers concentrate on architecture, domain modeling, and production readiness. The work does moves from writing code toward specifying what should be built, reviewing what was built, and deciding what is correct.
It reduces the cost of the first working version, but it changes the cost of everything after it far less. The savings concentrate in scaffolding, prototyping, and exploring alternatives, while production hardening, integration, security, support, and maintenance stay roughly where they were. You have to budget for the system’s whole life rather than its first demo, because custom software means you own maintenance, uptime, and roadmap for as long as you run it.
AI models have a lot of knowledge without judgment about where that knowledge applies. They may have read everything public about real estate, but they have never seen how a specific firm works. So, a generic model produces software that looks professional but misses the distinctions practitioners rely on: concepts that seem similar get merged, fields that matter get buried, and the result stores data without supporting the reasoning behind it. Domain expertise catches those mistakes before they are built in, when fixing them is still cheap.
Ask them to explain one of your domain objects back to you, and listen for whether they know which distinctions matter. Then ask what they would deliberately not use AI for on your project, who reviews generated code and against what standard, and what happens after launch: who answers the phone, what maintenance costs in year two, and what happens if you take it in-house. A partner who agrees with everything in a scoping call is optimizing to win the work rather than to build the system.
Having 25 years of CRM consulting experience, Wes has been on multiple advisory boards for CRM applications over the years including Salesforce, Dynamics 365, and no less than 10 other CRM platforms. Wes is a frequent guest of podcasts, speaker, and author of posts on CRM topics.
(4 votes, average: 4.90 out of 5)
Loading...