The Project We Sold Before We Knew How to Build It

The client approved the proposal on the same day I sent it.

Under normal circumstances, I would have been thrilled. Instead, I sat in front of my computer wondering how I was going to tell Johnny that I had just sold a system neither of us knew how to build.

The budget was about five times larger than a normal project for us. The client was a national youth organization with thousands of counselors and chapter leaders across the country. Until then, we had never worked with an organization of that size, and we had definitely never charged that much for a single project.

I knew what having their name in our portfolio could do for the business.

I also knew Johnny was going to think I had lost my mind.

When I first started building websites, I wasn’t really doing development.

I worked mostly with a closed website builder that allowed me to create almost everything visually. For standard marketing websites, it was more than enough.

My strength was never the platform itself. I was good at sitting with a client, understanding the business, organizing the content, and figuring out what the website needed to say and in what order.

I was also a strong designer. I could take a fairly ordinary local business and give it the kind of website people associated with much larger companies in New York or London. Once the design was approved, I knew how to reproduce it closely inside the platform.

That was the service.

I wasn’t building databases, advanced search systems, or custom administrative tools. I wasn’t writing much code at all.

This worked well until a client asked for something that the platform, and I, were not built to handle.

The first meeting took place at the organization’s offices in Manhattan.

They wanted to build a digital resource center for their counselors. Over the years, they had created activity plans, training guides, educational materials, and internal resources covering almost every subject their teams might need.

Most of it was not online.

It was stored in binders.

There were shelves full of them, organized by age group, topic, activity, and year. If someone needed a particular guide, they had to know which binder to look in and where that binder happened to be.

The organization wanted to put all of it into one system. Counselors across the country would be able to search the library, filter the results, and find something useful without calling the main office or going through years of printed material.

The planning did not scare me.

There was a lot to work through, but I understood the problem. We would need to decide how to categorize the materials, which filters were actually useful, how the search should behave, and how to present a large amount of content without making the system feel like another storage room.

I could also see the design in my head.

The part I could not see was how we were going to build it.

Johnny had joined me part-time a few months earlier.

He was not my partner yet, but by that point we were already working as a team. He had experience building websites on an open content management system that allowed for more customization, more complex content structures, and actual development work.

For us, it was a big step forward.

We could finally offer clients things that were difficult or impossible on the platform I had used before. We were no longer limited to polished marketing websites.

Still, there was a large gap between the websites Johnny knew how to build and the system this organization wanted.

He had never built anything like it.

Neither had I.

The sensible thing would have been to come back from the meeting, sit down with him, go through the requirements, and decide together whether we should submit a proposal.

I did not do that.

Johnny is careful.

He likes to understand how something will be built before agreeing to build it. He wants to know how much time it will take, where the difficult parts are, and what could fail.

That approach has saved us from many bad decisions over the years.

It also means his first answer to an unfamiliar project is usually no.

I already knew what the conversation would sound like. I would explain the system. He would ask technical questions I could not answer. Then he would tell me we should not promise something we did not know how to deliver.

He would have been completely reasonable.

That was why I did not ask him.

I sent a proposal for the entire project.

Not just the planning or the design. The complete system.

I believed we would find a way to build it, although that belief was not based on any technical plan. We had learned new things during projects before. We had become good at solving problems while working.

This was simply a much larger problem.

I did try to protect us financially. I priced the project high enough that if we reached a point where we could not continue alone, we would have room in the budget to hire a more experienced developer.

That part of the decision was calculated.

The rest was me wanting the project badly enough to believe we would figure it out.

A few hours after I sent the proposal, the client approved it.

I walked into the office smiling.

Johnny looked up from his computer and immediately became suspicious.

I told him I had big news. Then, for some reason, I added that it could be very good news if he chose to look at it the right way.

That made things worse.

I told him the youth organization had approved our proposal.

He stared at me for a moment.

“What proposal?”

I started explaining.

I told him about the binders, the resource library, the content structure, the filters, and the search system. I explained that thousands of counselors would eventually need to use it.

Then I told him how much the client had agreed to pay.

He looked shocked, but not in the way I had hoped.

“How are we supposed to build this?”

I told him we would figure it out.

“We don’t know how to build this.”

I told him it was not beyond us.

He looked at me and said, “You’re insane.”

I said something about how we had always found a solution before and would find one again.

I sounded confident.

Mostly because one of us had to.

We decided to start immediately.

There was no final specification yet. We had not designed a single screen. The client had not approved the categories, the filters, or the way the system would behave.

Starting development at that point made very little sense.

We did it anyway.

We needed to know whether we could build the basic engine before going any further. It did not need to be attractive, and it did not need to match the final product. We just wanted a place where we could enter content, display it, search it, and filter it.

The client did not ask us to do this.

We were doing it because both of us were worried that we had accepted a project we could not complete.

The plan was to build enough of the system to calm ourselves down. After that, we would go through the official planning and design process with the client and adjust everything properly.

We stayed in the office for the next forty-eight hours.

We did not plan to. We just never reached a point where it felt reasonable to stop.

The first version barely worked. Then we fixed one part and broke another. The search produced strange results. The filters worked until we tried to use more than one at the same time. The content structure that seemed logical at midnight made no sense by four in the morning.

We kept changing things.

Sometimes we solved a problem. Sometimes we only replaced it with a different problem.

This was years before AI coding tools.

There was nobody to ask for a complete solution. We searched forums, read documentation, and worked our way through old Stack Overflow threads. Sometimes the answer was buried in a comment. Sometimes we found someone who had asked exactly the same question years earlier and received no answer at all.

At some point, we slept for about two hours in our chairs.

Then we woke up and continued.

By the end of the second day, we had something.

It was not beautiful. Some of the screens looked terrible, and several parts would need to be rebuilt later.

But the system worked.

We could add a piece of content, assign it to categories, search for it, filter the results, and find it again. There was an administrative interface. There was a content library. The main pieces were there.

I do not remember celebrating.

I remember looking at the screen and feeling relieved.

We had not solved the whole project, but at least the thing we had sold was possible.

After that, we began the actual planning process with the client.

We sat with their team and went through the materials, the categories, the way counselors searched for information, and the situations in which they would use the system.

We asked questions and took notes as though we had not already spent two days building a rough version behind the scenes.

The planning went well.

So did the design. We were able to take a huge amount of material and turn it into something that felt simple to navigate. Once the interface was approved, we connected it to the system we had already built and changed the parts that no longer fit.

There were plenty of problems along the way, but nothing close to the disaster we had imagined when the proposal was first approved.

The system launched successfully.

The client was happy with it.

Years later, we still consider it one of the best projects we have done.

That project did more than add a large client to our portfolio.

It changed the way we evaluated new work.

Before it, we usually asked whether we already knew how to do what the client was requesting. Afterward, we started looking at the size of the gap. Was it something we could realistically learn? Could we price enough room for mistakes? Did we know who to call if we got stuck?

We did not suddenly start accepting every project.

There are jobs you should turn down. Sometimes the technical gap is too large. Sometimes the budget does not leave enough room to solve unexpected problems. Sometimes confidence is just a nicer word for not understanding the risk.

But this was not the last time we accepted work that was beyond our experience at the time.

It was simply the first time it worked.

That gave us permission to keep doing it.

Being independent already involves risk. There is no guaranteed salary, no department to pass a problem to, and no manager waiting to make the difficult decision for you. When something goes wrong, the client calls you.

Still, it is possible to run an independent business very cautiously. You can keep offering the same services, taking the same kinds of projects, and solving problems you have already solved before.

There is nothing wrong with that.

It just was not how our business grew.

Most of our biggest jumps happened when we accepted something slightly earlier than we were ready for it. We left enough room to get help, understood that we might work far more than expected, and took responsibility for getting it done.

That first project was not proof that we could do anything.

It was proof that not knowing how to do something yet was not always a reason to say no.