How Long Software Projects Take: Data From 28 of Our Projects

Most software projects we take on need three to six months to build. Simple ones, such as a GoHighLevel sales setup or a Xamarin to .NET MAUI migration, take one to three. We checked that against the 28 projects in our portfolio. The portfolio records how long we worked on each one, including work after launch.

1. 01The numbers

   Across the 28 projects, the median is 8 months. The shortest took one month, and the two longest ran for 30.

   1. One to three months: 3 projects.

   2. Four to six months: 9 projects.

   3. Seven to twelve months: 10 projects.

   4. More than a year: 6 projects.

   The median sits above three to six months because these durations include work after launch, as the longest projects show.

2. 02Durations by type of project

   AI and SEO tools took 3 to 5 months: Money Ball, SiteRanker and Aiode.

   SaaS products took 4 to 8 months: Legal Atoms, Clicks.so, Whistle It, Natif.ai and Contakti.

   Compliance tools took 4 to 12 months: Alertia, Falcore, NPTAAS and Fisar.

   Healthcare platforms took 8 to 12 months: Nuvana and Microhealth. Slumber & Sprout, the one mobile app in the list, took 4.

   Marketplaces varied the most, from 1 month for Cinekit to 30 for Coach Catalyst. Mi Taller, Truck-4, Klingit and Cad Cam Masters sit in between.

   Ecommerce took 6 to 20 months: Westar, CashKart, Cercle, BuffyHub and AutoBuffy. Two long-running platforms, One40Connect and ATC, ran for 24 and 30 months.

3. 03What made the short ones short

   Cinekit took one month. It is a camera and production gear rental marketplace for creators in the UK, Europe and the US. The scope was one clear flow: list the gear, book it, hold a security deposit through Stripe and return it. We built it on Ruby on Rails, which suits fast backend delivery.

   Money Ball and SiteRanker took three months each, and each does a single job. Money Ball answers NFL questions from a live stats database. SiteRanker tracks how websites show up in AI search.

4. 04What made the long ones long

   The longest projects were products we kept building, not single builds. AutoBuffy, ATC and Coach Catalyst each had a first version live within three to six months. Everything after that was new work.

   AutoBuffy’s 20 months covered an Angular upgrade, Elasticsearch search, a real-time inventory service and buy now, pay later at checkout. BuffyHub’s 19 months included syncing with Amazon, eBay and Walmart.

   The pattern is integrations. Every outside system, from a marketplace to a shipping carrier, brings its own rules, test accounts and failure cases. Compliance adds time in the same way: Fisar, a GDPR compliance tool, took 12 months.

5. 05Why projects run late

   When one of our projects runs longer than planned, it is usually for one of four reasons.

   1. Scope changes. New features get requested halfway through, and each one moves the end date.

   2. Integrations. A third-party API, marketplace or payment provider behaves differently than expected.

   3. Waiting on the client. Feedback, content, designs or access arrive later than planned, and the work waits with them.

   4. Unclear requirements. The real requirements only become clear once people start using the first screens.

   The first and last are linked. A short discovery phase and a written change process catch most of both.

6. 06Team size and hours

   Our eight case studies record the team and the hours. Five ran with two engineers, ATC and Truck-4 had three, and AutoBuffy had six.

   Hours ranged from 1,232 on Truck-4 to 28,000 on AutoBuffy. Klingit took 1,400, Nextflag 1,602, Cercle 2,112, ATC 2,800, BuffyHub 3,344 and Coach Catalyst 4,272.

7. 07How to plan yours

   1. Count the systems it connects to, not the screens. Payments, marketplaces, shipping and compliance rules add more time than pages do.

   2. Ship the smallest version people will use, then plan the rest as a series of releases. Cinekit’s one-month build shows what a tight first scope looks like.

   3. Plan for work after launch. Frameworks, app stores and payment rules keep changing, so live software needs regular attention.

   4. Agree who signs off each milestone, and how quickly. Late feedback moves the end date as much as late code.

   5. Keep the same team if you can. The engineers who built version one already know where everything is.