Serious News

Chris Duff

Get Your Land Sold, free when you subscribe

Serious News: the weekly land + AI brief.

More Instructions Won’t Make Your AI Reliable | Ep 323

Context

The SLC Deal Engine is live after a two year, $100K build that ran through Land Pricer, SLC Chat, and a Cowork plugin that kept breaking under its own patches. The breakthrough came from scrapping the vibe coded architecture entirely and rewriting the underwriting procedure as hard code, with AI reserved for the final pricing judgment. The finished engine prices a deal in roughly an hour at about 2% of weekly token usage on a $200 Claude Max plan, and installs at $2,500 plus $99 a month.

Key Takeaways

  • Hard code the procedure, keep AI for judgment. Patching prose instructions made accuracy worse with every fix, so the workflow was rewritten as deterministic code with AI limited to the final pricing determination and report.
  • Solve reliability first, cost second. The first successful end to end run took 3.5 hours and burned 15% to 20% of a weekly $200 Claude Max allotment. Optimization then cut it to roughly 2% and about one hour.
  • Validate in parallel, not sequence. Running three to five sessions against the same stage simultaneously exposed lucky one-off passes and forced 100% accuracy across 20+ rounds of testing.
  • Stop pricing to a single number. Land exits are probabilistic, so the engine outputs a range with a most likely exit instead of one exact price per acre.
  • Gate the IP server side. The earlier build left 95% of the code on the customer’s machine. The current one leaves only shell criteria and pushes updates automatically.

Want the Deal Engine running on your deals?

Shoot Chris a DM or an email and he’ll set up a call and send over the demo. And if you have deals for us to review in the meantime, head to seriousland.capital.

(Podcast transcript below)

We’ve spent over two years learning that you cannot make an AI project more reliable just by giving it more instructions. So we turned the procedure into software that cannot skip steps, kept the AI only for judgment, and graded it against an expert’s answer key until it matched, and then locked that entire method.

behind a server key that our company can revoke at any time. So that’s the base summary on what we’ve been up to with the SLC deal engine. Previously this was named SLC co-work plugin or SLC chat and even the earlier version, land pricer and software moves fast here. You we we have been in this stage of, you know, ship it or zip it.

for for quite a a while now. can’t tell you how many times they’ve tried to provide you know more firm updates on when we can get out a reliable land underwriting software to the community and then you know various tests keep getting pushed back and feedback says hey this is not what we need plus like just the expectations of

Customers are evolving faster than they ever have before in the history of humanity. I don’t think that is is a stretch to say that, given the capabilities of AI are are changing at such a rapid pace here. but really, you know, five minutes even before hitting record on this one, I am all set to record a demo for you know interested.

individuals and companies that want to use our software here. So I want to give you an update on just what’s been going on behind the scenes here. This has been my core focus. I’ve largely kept this under wraps just because I’ve cried Wolf too many times here. So, you know, for those of you who have been following this journey for quite a while here, you know, we had started the idea of creating a land underwriting software.

you know, really toward the end of 2023, early 2024. This was originally called Landpricer. And you know, this was way before AI became more sophisticated. And so, like the method that we built lived in this, you know, giant branching questionnaire with hundreds of scripted questions, tutorial videos, hidden waiting engine.

a confidence score at at the end. and we did get it to a a working spot. you know some of the pricing reliability at the very end was going to require some more tweaks. but ultimately we we did get it to a serviceable spot. and it was like the first time we had our land underwriting method existing outside of you know my own header, you know, serious land capitals

team brains, so to speak. you know, but it was also pretty slow to use, you know, fairly rigid in its application. plus it just needed a lot of hand holding from engineers and any time like we would have customer feedback or you know, even internal feedback. Like it just took it a long time to fix those bugs and you know try to deploy

updated versions.

And it also tried to do something that, you know, like I mentioned before, you know, the actual name of the company, Land Pricer, there was trying to like firmly price land. And so that’s what I mentioned, you know, some of the reliability issues. And so in our more more recent iterations, like we’ve stopped trying to do that one exact price. And anybody who’s been in the land game for a while, like understands there’s a probabilistic range of outcomes. and we

always indicate this, you know, whenever folks come to us for funding. And usually we, you know, hedge our bets on the most conservative price, again, downside protection being most important. But like plenty of times we’re like, hey, we wouldn’t be surprised if you could exit for that number that you’re saying it here. But we would be more conservative in the case that the market is not quite as strong as you know, we we might expect here. I mean, just look at the market now, how many times you have to do price cuts and figure out

know that’s why we build in downside protection in the first place with with the buy. So now we provide more of a range as well as like probabilistically where the exit most likely will be. and so like with the land pricer side like it was this more lengthy guided walkthrough. I mean originally there was just so many questions. It took like an hour plus just for the user to go and like dig up and answer all these questions like pretty unwieldy.

to to use and like required them to do a lot of you know tool side work initially like potentially double checking items on land ID and redfin and so forth. And we tried to automate some of that, but it it it still like even when we cut down on that guided walkthrough considerably, which we did, like it it still

you know, required users focus to actually be be going through that. And it still required like some subjectivity. There was some user level error on how they might judge comps to be related to the subject property there. So you know that introduced it its own set of complications. anyway. you know

Even though we shifted away from that method, and again, that was an entirely separate business. and ultimately like that was too much lack, you know, split focus between our serious land capital business and land pricer, its own team and branding and so forth. but getting that method down, what we did for Landpricer was the ultimate real asset. Like, you know, all those Loom videos recorded, like all of that on how to underwrite properties.

Sure, methods can always update a little bit here and there, and you can adjust based on you know certain geographies, but like the core principles of that still held true, you know, regardless of what and underwriting program we we built later on. so you know, every later version of this, you know, deal engine, so to speak, was just a faster and a stricter body.

Wrapped around that same spine that we had spent, you know, hundred K in my own personal dollars, and just you know, ungodly amounts of of hours. banging my head on trying to figure out how to to work that. but you know, we figured out the the method here. So you know, we had a great starting point as technology.

evolved to then implement into techniques that fit needs of users more reliably and also didn’t require you know huge amounts of investment or you know both time and monetary from my own side and something we could still do within our own core business. so earlier this year, you know, recording this in August 2026, you know, this is after the advent of

Cloud code and agentic AI models here. When again, that this was like the the real J curve that that started in terms of AI capabilities here. and you know, tools like Replit and so forth, where you could start five coding your own apps and and all of that, implementing Cloud API, and you know, just less hallucinations from AI models. so some of you maybe remember.

as we went through this next iteration, like okay, revitalizing what we had done with land price or and now rebranding it as SLC chat, where the intent was to be a you know Krista brain, effectively or serious land capital brain of all of our underwriting knowledge and you know market insights and so forth, utilizing all the

publicly available data that we had pushed out as well as a lot of our internal data to inform this you know, chatbot engine that could both price deals as well as you know act as a pocket Chris for your land company. and critically here is that like we could use that entire

Pricing engine, and you know, more reliably build out, you know, that customer-facing software. And I wrote about this at length as well, too. but you know, the shorter version of the story ultimately was like it was still too unwieldy for customers. And again, this is like as customer expectations again were evolving week by week to where it was like, hey, even the

e even having to input you know some basic parcel related data like even you know

Acreage and you know, figuring out well, not not the acreage piece. That that that’s pretty simple, like pretty standard to to implement there, but more of like, okay, what are some baseline comps that you had already identified for it? Like you still having to do work for the property versus like just plugging in, hey, here’s the APN, here’s the county of the state, like go price this property.

Like that is all a user really wants to do. That’s all I want to do within my own business. but having to do any of that or like prep a due diligence package and so forth was like a bigger disappointment and key feedback that we received and ultimately I I agreed with and at the same time too is like trying to run it through a replet server,

having to work through Claude API. You know, again, token costs are always generally decreasing and you could use some of those open weight models and so forth, but it wasn’t quite as available at the time we were building that. and it was super expensive to run. to where you know we were having to price, you know, like a base package of being able to run like, you know, one or two deals in a month.

For at like at least $20 a month. And like, you know, to run even more than that would have to be at least $100 or or more. so it was like a premium price for a product where the customer experience would be lacking. And like the margin on the back end for us was limited because we had to eat such, you know, expensive token costs on behalf of the users. And we couldn’t like

Allow as much, you know, unlimited usage because it was going to cost us too much and be like a loss leader. So that approach also was experimental, very informative, but you know, made us realize: hey, like we really need to make this more agentic to fulfill customers’ needs as well as our own needs. like I wasn’t jumping to use that in our own business. And so it was like, you know.

Introducing full agentic web browsing capabilities into a replic model is not recommended because a lot of the base LLMs, like Claude, for example, or ChatGPT already had this built in. So it’s like, okay, can we just take everything that we did within this SLC chat repli build, move it onto cowork, and

this kind of kills two birds with one stone. First, we get much increased capabilities by being by being able to utilize, you know, co-work agenda capabilities, Claude and Chrome, which was getting better at at the time again, too. Cause again, like AI is just evolving week over week. so we’re able to, you know, adapt in in real time based on the evolution of the technology. and also

We would be able to shift the costs of the tokens onto the customer. So if they had a a Claude plan, which you know a lot of people do nowadays, yeah, theoretically it would limit our total customer base a bit more for people who didn’t have Claude, but for people who did, it was a way better product and it it reduced, you know, a massive cost burden that we would have had to been eating internally.

however, this was at the cost at the time of you know having to run the entire software on the consumer’s computer so they would be able to see and you know, basically copy over you know, even if you’re a benevolent actor, it introduces edge cases of possible competitor copying and so forth, especially you know, any product that starts to get success, inevitably somebody’s gonna try to copy it.

And take some of that success on on their own. I mean, I d no hard feelings about that. Like that’s just the way capitalism works. done it plenty of times myself. I think everybody has that’s run run a business. you know, you you borrow or steal what what works, right? So, and try to do it as as ethically as as possible, compete within your your own lane. But you know, just

realistic with with what to expect. And so, you know, that was a risk we were gonna have to take. So it’s like, okay, we could introduce some legal language to this, and we found a way to gate some of the most critical intellectual property, like exactly how we price the properties. It would still show like the full result to the user, but it wouldn’t tell them the exact math behind the scenes. And it would also allow us to gate from a pricing perspective, you know, we could revoke

API keys, if people stopped paying the monthly recurring update fee and so forth. So it gave us some more protection, but still allowed us to give like very individualistic boutique white glove install service for people who was who were even like slightly tech savvy and had a claude subscription. So that was our adjustment from that side. And this is also, you know, as we were undergoing

Testing for reliability was determining, yeah, we can’t just do like in, you know, price equals X for the output here. It was arriving at that range. you know, l like I had described earlier. and so, you know, when we first started exploring this two, you know, I thought it was going to be a much quicker build, but building

Building this thing reliably. Again, you know, software takes a while. I was all, you know, also had my second kid write as I was you know, building out this cowork plugin. And so, you know, things just got backlogged for a while. Any, you know, new parent can can understand. if you don’t have kids, I mean, I’m sure you you you’ve heard or seen some from from some of your friends or relations. and so I was dealing with that at the time, and we we had onboarded an early customer and you know.

gave ourselves a deadline to deliver on that for the the cowork plug in. And we ultimately did hit that deadline, or at least we we got like a small extension within like a week or two. So this puts us at by, you know, mid July roughly. and I was becoming a lot more confident with how the deal engine was was working. and I was routinely more

Or utilizing it on deals that were coming into our own system and testing it against manual reviews of deals that were coming in. And these were subdivides, you know, single flips and so forth across all different states. And it’s like, okay, this is this is becoming pretty reliable. you know, some some tweaks here or there, but you know, I was figuring out how to do, you know, the quality assurance.

in in better formats. Okay, I can just rec record a loom afterward and, you know, be able to

Correct the errors after and you know, I was just working with with cowork to okay update the the code here. and you know after we had given it to this initial customer, you know, I kept testing this, but like the consistency was just

It wasn’t quite as reliable as I would have looked like. Like I I think I got a little overconfident based on some early accurate returns. or like my manual output for a deal was like, you know, arriving at, I don’t know, 8,800 price per acre. And, you know, the deal engine was showing, you know, nine K. so like, yeah, this is this is pretty darn solid here.

However, like additional reviews, even on the same type of deal, was just getting like wildly off. And sometimes the variance was just increasing the more I tried to fix it. And it was getting worse and worse. and

Yeah, so at at at this point, this was really like the crux of determining whether whet whether the build was going to to work or not. and it was kind of like a hey, prove it or potentially bail on this. Like it was a it’s an open question of like, you know, i the technology is getting better here, but can it quite handle the

necessities of and and you know reliability that I need to be usable in my own business and and put it in front of customers here. And like the this was a you know admittedly like darker few days as I was trying to figure figure this out. Cause I’m like, man, is this like I’ve spent s you years now trying to figure this out and like it it’s still breaking down. I can’t figure out this reliability piece. And I might I kind of have to go back to my audience and tell them

you know, hey, I just couldn’t figure this out. I couldn’t deliver on this again. you know, ultimately that that’s a risk of any business. And, you know, public promise you you make out there, not everything’s gonna hit the outcomes that that you want. but you know, I was just feeling a lot of disappointment and frustration on on where the the product was and also like the live customer I had. I’m like, man, I just delivered this.

But now it’s almost like the quality is getting even worse the the more I’m trying to improve this. And so like I really sat down with with Claude and like, okay, let’s just like restart, like look at this architecture and really determine like look through every single piece here and just be honest with me. Like, do you is this a feasible build?

What what do we need to do here? Do we need to break down like every single loom and improvement video that we did and do this on like a five minute by five minute segment? Do we need to need to do smaller steps in order to get things you know moving in the right direction here? and this is really where we started hitting some critical breakthroughs. And ultimately we we started rebuilding the entire architecture of of the build. not like the core.

you know, pricing components and everything. Like the knowledge base was still feeding feeding the product, but it was just the way things were coded to build in more reliability. and so

you know, b a whole bunch of lessons throughout throughout this process.

but ultimately where we landed was that okay, so much of this you know, current build has just been like patch upon patch upon patch and is relying too much on pros to define what should be you know code specific actions here. And I get it like

This starts to become very, you know, engineering heavy language here. but to be, you know, to try to put it in as much plainly English as possible is like, again, we we’ve referenced vibe coding earlier before. And like that’s something anybody can do. And what we had been doing for quite a while, it’s like, hey, you have this idea. I’m gonna take it to cowork, I’m gonna take it to Claude Code or ChatGPT codecs and so forth.

open claw doesn’t matter and I’m just going to feed it my idea and you know Replit is another example just so many of these sites and tools and then you can just spin up a website or an app and just you know build whatever you need and then you know deploy it accordingly. but as we found out and as a lot of these tools would warn you is that oftentimes if you patch software that

might just break something upstream. and then you have to patch that. And then that could like make your downstream issue even worse than it had been before. And so like that’s what we were running into is just patch after patch after patch. Like it was vibe coding setup. It was not a disciplined architectural build. so that was like I’m almost glad we went through this because that that was the breakthrough that we needed for this particular software to really start working. And

Also, the breakthrough I needed for our AI implementation arm of the business. For yeah, if we’re working with other companies here and trying to solve their core constraints with AI workflows, like I I kept coming back to the proof point of you know, if if I can’t build a real receipt here, like if I can’t build a system in the business I know best.

which is within land and been working in this for years and just have a deeper expertise in than you know almost anybody in the world and you know for anything that I know personally in my life. if I can’t figure out that then like how can I honestly go to other companies and attempt to build workflows that can solve their core constraints here. So it was like a flywheel I was trying to build to prove it out to myself as well as other potential customers.

that hey, we really know what we’re doing here. And so like that breakthrough of understanding the difference between true vibe or you know vibe coding versus real disciplined architecture was just such a massive unlock. And so you know as after we hit that unlock then it was okay this architectural rebuild and we went through all these validation exercises to determine, you know, okay, we have

certain properties we’re trying to review here. like we’re going to test it in a very disciplined fashion, stage after stage after stage, and and you know, do multiple stages all at once because like like we saw, for instance, you know, sometimes we got lucky on a on a certain review. but it might not build in more reliably. So it’s like, okay, do we do, you know, three sessions, five sessions in parallel here, all along the same stage and see if we continuously hit

100% accuracy every single time. That’s what we did. Cost a ton of tokens to do this, ton of time. but that was ultimately the route that started to allow us to build the much more reliable, robust version of this product that was all based on hard coding rather than prose level architecture. And we really saved the AI component, like just for kind of the final

Pricing determination and kind of taking in all of the data that we’ve scraped and pooled together and then determining, okay, based on this and all the various rules, how do we orient the land investor on the back end for how to consider it all? Like that’s that’s where the AI really comes to bear here. But a lot of the earlier parts is you kind of have to remove that and just make it much more hard-coded.

plus it’s a lot more token efficient. If you just you know hard code everything out, you you don’t need to burn tokens. You’re not wasting AI tokens and w if it’s just all all written into code. You only have to burn the tokens to actually write the code i i itself here. So that

Yeah, was was a massive breakthrough. And like this was multiple rounds that we had to go through, like 20 plus rounds of just figuring out how to validate and improve this. you know, different subsets, different bugs that I had to find. I had to just QA engineer our way through it. And again, like really pay attention to it. Like this is why I keep, you know, coming back to that Sharan Srivatsa, you know, the decide, build, check and then run formula within your business and the check.

just how important and how valuable that is. Like in the age of AI, like that, that is a thing we all have to be doing as humans. When I keep telling my team, keep telling myself, like oftentimes it’s boring. I don’t want to do it. But, you know, I have to be reading this output within Cloud Cowork, within Cloud Code and seeing, okay, wait, this line does not really make much sense here. And you know, anybody who’s using AI as well too, it’s like you can come across as so confident and it knows what it’s doing. It’s just flying through things, but you have to be able to

Determine, hey, no, this does not seem right. Can you answer how exactly you got to this conclusion here? I don’t think that’s correct. And so like some of these are really nuanced little pieces that again can like make or break the final version, or at least the best possible version of the product that you’re trying to build. so I had to be paying attention. I had kept having to go back and forth to figure that out.

And so yeah, we just basically ran through a whole bunch of test stations, you know, not the whole assembly line, like, you know, different validation. you know, again, like if you actually saw what this looked like in the back end, you’re like, dude, this is just crazy complex. And it’s not like I’m a deep, you know, front end back end engineer either. but you know, I have the AI explained.

Things to me more in layman’s terms, like what it’s trying to do. Like it, if you have the most powerful engineer, the best engineer on the planet in your pocket being able to run this stuff, but you still need to understand, at least again on a layman’s level, in plain English, what it’s doing, because then you can direct it further to run through all this complexity and all these various parallel tests that like I wouldn’t have conceived of.

myself, but I just directed it more of like, okay, the way that we’re doing this is not working. What do we need to do to ensure reliability? Like that line of thought process and pushback is what led to all of this validation here. and then, you know, it was a process of okay, let’s really determine the accuracy here. and

ultimately we did a full run, full live run on a particular property, like quite a difficult subdivide to review, even manually. It took like you know close to an hour to really determine it. A lot of weird comps and so forth. and this initial run was like three and a half hours end to end. And it cost, I and I’m on like the highest Claude Max plan, $200 a month.

And I think it costs somewhere around like 15 some odd percent, maybe even closer to 20% of total token usage for for the week, like massive token expenditure in order to run this. But it ended up getting the the right conclusion at the end. So it’s like, hey, that is the hardest part to figure out. We wanted to figure out the reliability, making sure all these systems work.

Now, yeah, okay, this costs an insane amount of tokens, you know, tons of time as well too. Now we can start figuring out how do we optimize that piece while maintaining the reliability. But we had like I would have thrown, you know, five Claude accounts. I would have just, you know, created different accounts for that in order to figure out that reliability piece. And as soon as we got that, then we can optimize.

But we had solved that hardest point. And like that was the big relief. I’m like, okay, the technology is here. We can do this. now it’s like, okay, let’s go back. How do we make this much more efficient? And from a token perspective, you know, I was utilizing you know, on cowork, just an opus five model, which is like not as expensive as Fable, but still a very expensive model. And

but you know, when you’re working on cowork, would the whole intent was doing it on cowork because it’s like a little bit more user-friendly than Cloud Code. and so I was using that from a customer perspective. but ultimately it’s like, hey, this is going to be a limitation for us because if we need to cut down on tokens, we need to have various models be able to run different parts of the software for us. Like if we’re just trying to spin up

you know, z scraping comps and so forth. And we have an appify connection as well too. Like if you’re if you’re trying to run this without Apify, it was like even that much more expensive. So it’s like really critical to have that. And yeah, we got the Appify spend to be like sub 50 cents per run. I mean barely anything, but makes it so much faster to to utilize. And Appify is basically like a a a scraping API software. So I could go to you know Zillow, Redfin, whatever, scrape a whole bunch of data and then

that made our our runs much much quicker and and cheaper to run. But in order to like, you know, do some of those early validation and, you know, multiple different agents running the these processes in parallel, it’s like, okay, I want to use cheaper models. And so like again, we went through the validation process and we went from like, okay, using the different claw models, all trying to run the same validation process and seeing which one broke and which one could be more

Consistent, which one is like the minimum level of model that we could use that would cost less tokens, and only using the higher powered ones at the very end for like the consolidation report. And so we went through that process, for instance. and ultimately within Cowork as well, too, is that you know, we had to use Claude and Chrome a lot, like moving users onto land ID and Redfin and like really checking true pricing history and the various overlays on.

Comps and the subject property. but when you use Cloud and Chrome, it it it can only run one agent at once. So you can’t run it in in parallel. But if we have, you know, I don’t know, 15, 20 comps to look at, that’s what takes hours to to go through. So that’s why we also moved to the claude code setup. And so we could have multiple browser sessions working all at once, and so you could run this in parallel instead.

again takes a bit more tweaks from the user to get all of this set up, but something that we walk through users on how to do. And that was able to collapse time a lot more too. And, you know, various other methods not worth getting into, but we were able to you know, get the token cost down on a Cloud Max plan to like two percent roughly of total weekly usage, like way better. I mean these are

almost an order of magnitude better than some of the earlier runs. And the, the, the total run in terms of timeline, like start to finish, like closer to an hour. which I I was out of all the things, like yeah, three and a half hours is like way too long, but I really did, you know, out of all the factors, I cared about reliability most, token usage second most, and timing the the least. because like this is really supposed to be

You know, hey, I’m just throwing a a deal. Hey, price this property. That’s all I need to say to Claude. Like that’s it. And it’ll do the rest for me and give me the report at the end. You know, build me a whole Excel file, all the comps that it had found, which one were used in the pricing analysis. So then I can just read it out like a TLDR report as well, too, in in writing, you know, plain English. so who cares if it takes an hour, right? And I could potentially do multiple of these at at one time. you know, probably can

you know, get that e even faster going going forward here. But like it that’s a pretty good a a pretty good setup. so once we really saw this, the next piece was testing on a couple of other different properties to make sure it could work in disclosure and non-disclosure states, subdivides versus flips and so forth. and then we also realized hey, we could change the underlying architecture, well of of where

The software was hosted to be, you know, much more gated server side than it was before. Like I had mentioned earlier, you know, the the first version of this cowork plugin, like 95% of the code lived on the customer’s computer. So, you know, even though the most important part was still on our side, you know, the actual pricing mechanisms, you know, a savvy.

competitor would have been able to pull and you know adjust the the tool on on their own. So you know, through some, you know, more clever engineering, we ultimately determined, hey, we could probably gate this even more and still ensure that we’re maintaining the same, you know, token cost and reliability and so forth. It’s not breaking. but let’s just gate like everything.

behind server side access. and so we were able to accomplish that as well. And so now the only code that lives on the customer side is like basically shell criteria. Like it knows how to pull the info from the the actual core software but you know the core IP none of it lives on the customer side and but

Yeah, ultimately this is a better customer experience because now it’s really just like a one-time install. Still a bit boutique, like you have to go through the terminal and all that. But again, that’s like what we’re here to work with with the customer initially to install it on their system. But then because it’s server-side, it the the updates are much more simple to go through and it still allows the individualistic nature.

To where we have a knowledge base file that any user can just work with Cloud Code to update accordingly. And it learns, you know, the more deals that you do through this, the smarter it gets. And it also realizes: hey, you work in, I don’t know, California or you know, Texas specifically. So it orients more of its core knowledge to go into that. And so then it refines the the deal engine further based on your own specific.

needs, or maybe you know, you’re a wholesaler and you price things at, I don’t know, 70% on the dollar or 70 cents on the dollar versus 50, for instance. And so like your pricing engine might be a bit different than than ours and it calibrates accordingly there. So, or or maybe you work with a specific realtor and di different commission rates, or you, you know, you sell everything out outside of you know, working with realtors, so you can just build all of that in. So all of that can remain individualistic.

And you know, kind of best of all worlds. It gives us our core IP that we can guard and update more reliably. And for the customer side, you know, updates are just pushed as often as we push them on our side and it doesn’t require consistent install. So like it’s like any software that you use, like things should just be live. You know, you’re using your iPhone, an app updates itself, boom, you don’t need to do anything, it just shows up. That that’s exactly how this software works as well here. So

That is where we’re at as of today here. like this has been just a wild journey, but I’m I feel this is like the absolute bleeding edge of software design. and like I’m in touch with a lot of very talented engineers and try to keep up with the processes that that they’re utilizing at at their own companies and so forth too. And I feel like we’re right there.

so I’m very pleased with how this has turned turned up. I’m gonna be recording the you know demo here shortly. but you know, if this is of of interest to you, you can you can DM me, leave a comment here. I can you know, set up a a call, shoot, shoot you over the the demo here. and I’ll just name the pricing here. You know, it’s $2,500 for the install and $99 a month for standing access and all of the

updates that we are routinely making here. So, you know, higher up front given all the work that we had done here. But you know, again, to have our underwriting capabilities and a truly agenc tool, I know for a fact there isn’t anything else like this that’s as reliable on on the market here that holds to Serious Land Capital’s underwriting standards and is frankly this easy to to use.

Then you know, I’d love to have a conversation so we can get you all set up. but with that in mind, I will sign off. You know, if you have deals for us to review, seriousland.capital. If you’re interested in AI implementation for your own business, check out seriousland.capital slash AI. and again, if you’re interested in getting this deal engine installed, shoot me an email, shoot me a DM. happy to have that conversation. Subscribe and share, everybody. Looking forward.

to next time.

Related Articles:

Before you go: take the playbook

Get Your Land Sold: the exact tactics behind our $606K exit in the hardest land market in decades. Yours with your first issue of Serious News, the weekly land + AI brief thousands of serious investors rely on. Syndicated on RETipster.

Free guide, one brief every Monday. No spam, unsubscribe anytime.