Project time estimation – how 6 months turned into 1.5 years

View on X

"It always takes longer and costs more than you think." This quote hits me now like never before - I feel it with my whole being.

Initially, I thought I would finish the Advoo project in a maximum of six months. However, after 6 months, there was no end in sight, I was a hundred years behind. I thought then "since I've already started, I have to finish." It seemed to me that three more months of work would be enough, but after another three months, the situation repeated itself and ultimately the work lasted 1.5 years before the project saw the light of day.

Where did such underestimation come from? The main reasons are lack of knowledge/lack of experience/too little time for prior analysis.

Where did such underestimation come from? The main reasons are lack of knowledge, lack of experience, and too little time for prior analysis.

To estimate time, we intuitively try to break down one large task into smaller parts and so on, until we reach elements small enough that they can be estimated relatively accurately. This can be represented in the form of a tree, where subtasks are successive branches. If we underestimate any branch or - worse - completely omit it, the estimation grows.

🌿 Below I present several branches that turned out to be underestimated or even completely omitted:

☁️ Infrastructure – big challenge, even bigger underestimation

Building infrastructure I remember as one of the more difficult challenges in the entire project. I don't feel like a DevOps specialist – on a daily basis I deal mainly with development, and I have contact with infrastructure rather sporadically.

I already had some AWS basics – I had done a smaller project using this cloud before – but this time the scale was much larger, and many new services appeared that were new to me.

🔐 Security and scalability – things that cannot be omitted

I had to take into account greater emphasis on security, which involved using private VPCs and firewalls. Scalability is also a problematic issue - if your application is supposed to work on more than one instance, many things can no longer work "in memory", but you must then use intermediary services - for example, for the need to use WebSockets, I had to additionally use Amazon MQ.

🛠️ Debugging – walls and patience

Debugging errors in infrastructure is also not among the simplest - maybe it's a matter of experience, but sometimes I spent the whole day trying to solve some configuration error, hitting so-called walls.

💳 Stripe:

I had never implemented a payment system before (not counting simple cryptocurrency integrations), so getting into Stripe turned out to be quite a challenge.

I needed a subscription model, so the choice fell on Stripe – however, the entry threshold here is quite high. The biggest problem? The enormous number of possibilities and very extensive documentation in which it's easy to get lost. Before I even started writing the first lines of code, I had to spend long hours understanding how it all works – flows, webhooks, event cycles, implementation nuances.

The subscription system itself is also not obvious. It's not just:

purchasing a plan,

but also:

canceling subscriptions (where access remains active until the end of the billing period),
changing plans – both up and down,
failed payments, retries, notifications,
and all the logic related to transaction security.

If users are going to have complaints somewhere, it's most often in errors related to payment handling. And this means that everything must be very well thought out and refined.

Ultimately, I don't know exactly how much time went into this, but I know one thing: definitely more than I assumed at the beginning. And it was really hard work.

🧾 Bureaucracy

Let's not beat around the bush: Poland is a difficult country to run a company, especially when you want to do it according to regulations. At the beginning of the project, I practically didn't include this stage in the plan. I assumed that formal matters would take maybe a week, maximum two. In practice? It took almost two months – and not on writing code, but on paperwork, GDPR compliance and integrating the application with legal requirements.

📑 Legal documents

Terms and conditions, privacy policy, user consents, checkboxes, data processing clauses, encryption of personal data – all of this had to be:

created (fortunately I didn't write it),
understood (to know what the application actually has to do),
and then implemented into the application – at the UI, backend and logic level.

🏢 Setting up a company

Setting up the company itself took two weeks. And not because it was technically complicated – simply:

each action required logging in through a trusted profile,
there were many documents,
every click on the government website ended with another window to fill out or sign,
system errors and unintuitive forms appeared.

Many documents had to be prepared manually. I logged in with a trusted profile probably 50 times during those two weeks. I had the impression that government systems were designed specifically to confuse the opponent.

Setup production.

🚀 Production setup – meaning it's not just "deploy to production"

I definitely underestimated this stage. This was my first time when everything had to work in production – integrated services, publicly available, compliant with external vendor requirements. Earlier I thought: "I deploy the application, click a few buttons – and done." Reality? Completely different.

📤 AWS SES – getting out of sandbox

Using AWS SES – the email sending service – as an example, it turned out that by default it works in sandbox mode, meaning it only allows sending emails to approved test addresses.

I naively assumed that getting out of sandbox was just clicking a checkbox and confirming consents. Meanwhile, AWS requires:

written justification of why and how I plan to use email services,
providing the expected number of messages, type of content, contact details,
describing the usage model, security and abuse response plan.

If something is missing – the application is bounced and you have to correct it, write it again, contact support. Finally, obtaining production access took several days – and only because we reacted quickly. It was similar with SMS sending.

📅 Google API – YouTube video

The application integrated with Google Calendar, which meant using "broad" scopes (i.e., access to editing, saving, reading, etc.). To obtain production access:

You had to fill out a special application form.
To the form, I had to attach a video file (yes, video!) that shows the exact use of each of the requested scopes.
The video had to be published on YouTube, and the link pasted into the application.
Additionally, Google required:
- description of the application architecture,
- privacy policy,
- contact details,
- compliance with specific security standards,
- and of course, the application running under a production domain.

Time to process the application? Up to 3 weeks. In our case, we managed to get acceptance in 2 days — but only because we met all the requirements on the first try.

🔍 SEO – meaning not just Lighthouse and a fast page

At the beginning, I had a very simplified idea of SEO. It seemed to me that it was enough to take care of page performance, green indicators in Lighthouse, maybe some ALT tags for images – and done.

Nothing could be further from the truth. When the moment came to actually take care of the application's visibility in Google, it turned out that:

SEO is dozens of elements that need to be understood and implemented,
a large part of them has nothing to do with performance

I also realized that:

SEO doesn't work immediately – it's a long-term game,
SEO analysis tools often show different things than Lighthouse
for full understanding, a technical audit and understanding of how crawling and indexing work is needed.

I admit honestly – I spent more time on this stage than I assumed, because I simply wasn't aware of its complexity. Most of the SEO work was created after the application launch. This topic definitely deserves a separate article – which I plan to do.

➕ Additional features.

At the start, I assumed that the MVP version of the application was about 30% of what was ultimately created. From today's perspective, I see that this 30% should have been enough. Unfortunately, during the work, the project vision began to change – new ideas appeared, additional "needed" features, further improvements. Some of these things actually turned out to be useful, but many of them – from today's perspective – weren't necessary at all. The problem lay in the lack of experience with building MVP – I didn't quite know where to draw the line between "good enough" and "perfect." Intuition said: "add more, it will be better." Reality showed: "more = slower." From today's perspective, I can say that perfectionism and adding more features was one of the main reasons why the entire project dragged on significantly beyond the original estimation.

⚖️ Understanding the industry.

I had never used legal services before — maybe except for one visit to a notary. I completely didn't know the realities of this industry or the mechanisms that function in it.

My partner, with whom I co-create this platform, is a lawyer and knows the topic well. The problem is that the information he conveyed didn't quite "fit" in me. To put it bluntly — it was difficult for me to enter this world and understand it, at least at the beginning.

All of this meant that misunderstanding the industry also translated into the time needed to design a good implementation. I simply had to build some awareness before I could build the application.

🧳 Vacations, illnesses, moves

Vacations, illnesses, moves - everything that distracts from work, I didn't think about that either. Some plans appear suddenly. This causes overall project time extension.

That's it for obstacles, and now let's move on to things that accelerated the work.

🚀 Technology development:

How long does it take you to create a typical counter app – two buttons and a counter, where one button adds 1 and the other subtracts 1? You can probably estimate the time of such a simple task in your head. Let's say that today it's about 2 minutes – that's how long it takes to type a prompt into ChatGPT or another model that will generate a ready application in a few seconds. Before 2022, the same application could take 5 minutes – you had to write and test it yourself. And in 2005? Without modern editors, without AI, often without good autocomplete… Back then, even a comma instead of a period could effectively break the entire code and cost several additional minutes of frustration.

A similar productivity jump I noticed over the last 1.5 years, when AI went through considerable evolution. At the beginning of designing Advoo, artificial intelligence wasn't yet so developed – it didn't handle new versions of libraries that I decided to use well (which from today's perspective was a bit of a shot in the foot). I had to do most things based on documentation, because AI models didn't yet know the current syntax or changes. The breakthrough was the introduction of the ability to search the internet through ChatGPT. Thanks to this, I could give it a link to the documentation, and it was able to generate code compatible with the latest API or project structure.

This was a concrete boost. Another great addition was the so-called "deep research" – the ability to process information for several minutes based on data from various sources. This worked great for:

planning architecture,
choosing libraries and tools,
analyzing possible solutions.

A lot was also gained by spending $20 on the premium version of ChatGPT, which increased access to better models and higher limits. And of course — the continuous evolution of GPT itself, which from version to version increasingly better understood context and wrote code more in line with my work style.

📈 Experience and development – how the project taught me

As the work on the project progressed, I began to gain increasing fluency. Over time, such things naturally accelerated as:

modeling database structure and creating relationships between entities,
designing interfaces – I had more and more ideas, and at the same time better feel for what, how and where should look,
styling views – once it took me ages, now it went much more smoothly,
choosing appropriate tools – making technological decisions became more conscious.

I also made a big step forward thanks to switching to Terraform. Infrastructure as Code (IaC) allowed me to describe the entire AWS setup in text files, which AI handled excellently. Earlier, I tried to "click" everything manually through the AWS interface – and it was:

time-consuming,
not very scalable,
almost impossible to automate with ChatGPT's help (AI doesn't see the interface).

Then I had to rely mainly on documentation and YouTube tutorials. Terraform solved this problem.

⚙️ Next.js and other "new things"

Although I work with React on a daily basis, Next.js was a new experience for me. It's a different philosophy — routing, SSR/SSG, project structure, API routes – all of this I had to learn from scratch. Over time, however, I got into the rhythm and began to move smoothly in this environment, which also significantly accelerated the application development.

💪 Perseverance and diligence

At the beginning, after 8 hours of professional work, spending another 3-4 hours on my own project was a challenge. There were headaches, nausea, fatigue. But over time came habituation, better organization of the day, and developed diligence. All of this — experience, tools, AI, perseverance — together meant that subsequent stages of the project went increasingly faster, and the predicted completion time shortened.

✅ Summary

Underestimations result from things we don't know we don't know: from infrastructure and integration, through bureaucracy, to choosing the right MVP and ordinary life obstacles. On the other hand - AI, experience, better tools and systematicity can really shorten the path to the finish line.