The Day I Lowered the Ceiling

There was a point in the first version of this project where I had to admit something I did not want to admit.

The idea was too big.

Not bad. Not silly. Just too big for what I could honestly build, and maybe too big for what the market would even allow from the outside.

That earlier version was called BidPilot AI Suite. It was my first serious attempt at a construction bid platform. I was only about 18 messages into building it with the AI, but it already sounded impressive on paper.

We had a two-step AI quote builder. It could create versions of a quote. It had a bill of materials, which is just a list of what materials are needed. It could export a PDF. There was also an AI proposal writer that could help with a cover letter and a scope narrative.

And then there was the part that got me excited: live pricing.

In my head, this was the magic piece. A contractor would put together a bid, and the system would pull current material and freight pricing from suppliers. Less guessing. Less chasing numbers. Less stale pricing sitting in a spreadsheet from who-knows-when.

As a non-technical person, I had this picture in my mind that data was just floating around out there, waiting for the right software to plug into it. I had heard the term API before. An API is basically a way for one piece of software to talk to another one. So I asked the obvious question: is it realistic to get supplier API feeds?

That question changed the direction of the project.

The AI explained that for the kind of pricing I was imagining, especially live steel mill pricing, there really are not open feeds you can just connect to. Pricing is relationship-based. It depends on the supplier, the customer, the region, the quantity, timing, freight, and probably a dozen other things I do not even know enough to ask about.

In other words, the clean little software dream ran straight into the messy real world.

That was frustrating.

I had already started picturing the tool as if it could almost think and price like an estimator with a phone full of supplier contacts. But the app did not have those relationships. I did not have those relationships built into the software. And pretending otherwise would have made the product look smarter than it really was.

The price book we had was only placeholder seed data. That means sample numbers used to get the app working. They were not real market prices. They were not something a contractor should trust for an actual bid.

That was the uncomfortable part.

Because once I saw that clearly, I could not unsee it. If the pricing was not real, then the promise had to change. I could not keep building around the idea of fully automated live pricing if the most important data was not realistically available.

This is one of those moments where building with AI can be a little dangerous if you are not careful. The AI can help you create screens, features, workflows, and names for things very quickly. It can make the idea feel more finished than it is.

But fast progress is not the same as truth.

So I stepped back. The ceiling for automation was lower than I hoped. The tool could still be useful, but not in the way I first imagined.

That realization led me to restart and narrow the direction into what became MyBidPilot.us. Less fantasy. More practical. Less “the software knows everything.” More “the software helps you organize, write, and move faster, while the human still owns the real-world judgment.”

I did not enjoy making that turn. Part of me wanted to keep pushing the original version just because I had already started it. That is a very human reason to continue doing the wrong thing.

But I am learning that abandoning an approach is not always failure. Sometimes it is the first honest version of progress.

Small takeaway: If a feature depends on data you cannot truly get, it may not be a feature yet. It may just be a wish.