Where BidPilot Really Started

I started BidPilot AI Suite with a feeling I could not quite shake: construction bidding seemed like the kind of work AI ought to be able to help with.

Not replace people. Not magically know everything. But help.

Bidding has a lot of moving pieces. You need a quote. You need material costs. You need freight. You need some kind of bill of materials, which is basically the list of stuff required for the job. You need a proposal that sounds professional and not like it was written at 11:47 at night after too much coffee.

And you need versions, because the first quote is rarely the final quote.

That was the problem I wanted to solve for myself: turn the chaos of building a bid into something more organized, repeatable, and less intimidating.

At 50, with no coding background, even saying that out loud felt a little ridiculous. I was not sitting there with a team, a budget, or a software plan written on a whiteboard. I had an AI app builder and a stubborn curiosity.

The first version was called BidPilot AI Suite. Looking back, it was more of a sketch than a company. The whole attempt was only 18 messages before I restarted and moved toward what became MyBidPilot.us.

But those 18 messages mattered.

In that short first run, I tried to build a 2-step AI Quote Builder. The idea was simple enough in my head: enter the job information, let the AI help shape it into a usable quote, keep track of versions, produce a bill of materials, and export a PDF.

That felt huge to me.

I also wanted an AI proposal writer. Not just a price sheet, but something that could create a cover letter and a scope narrative. In plain English, that means: “Here is what we are offering, here is what is included, and here is why this makes sense.”

That part made a lot of sense to me. Writing proposals can be strangely hard. You know what you mean, but getting it onto the page clearly is another matter. This is one place where AI felt genuinely useful, like having a patient assistant who does not mind helping you clean up the wording.

Then I got to pricing.

This is where my big dream ran into a very real wall.

I wanted a live pricing module for materials and freight. In my mind, maybe the app could pull in current material prices automatically. Maybe steel prices, supplier costs, freight charges, all feeding into the quote like magic.

So I asked the AI if it was realistic to get supplier API feeds.

An API is just a way for one computer system to talk to another. So in my hopeful beginner brain, I imagined suppliers having clean little connections that my app could use.

The answer was sobering.

The AI explained that live steel mill pricing APIs do not really exist in the simple way I had imagined. Pricing is relationship-based. It depends on suppliers, accounts, timing, volume, location, and all sorts of real-world factors. In other words, this was not like pulling the weather from a website.

That was a disappointing moment.

I had seed values in the price book, but they were placeholders. They were not real market pricing. And once I understood that, I had to admit something important: the automation ceiling was lower than I hoped.

That phrase stuck with me, even if I did not use it at the time. The ceiling was lower.

AI could help organize, write, structure, calculate, and prepare. But it could not magically create trusted supplier relationships or live market data out of thin air.

That was the origin of the project: a big hope, a useful first attempt, and a reality check.

I did not quit, but I did restart. And honestly, the restart was probably the smarter move.

Small takeaway: sometimes the first version is not the product — it is the lesson that shows you what the product should become.