Skip to content
Costs & DecisionCustom SoftwareArtificial IntelligenceAutomation

How Long a Custom Software or AI Project Actually Takes

Real timelines by project type, what happens inside each phase, and the four things on the client side that delay projects more than any technical decision.

How Long a Custom Software or AI Project Actually Takes
In this article
  1. Short answer, by project type
  2. What happens inside the timeline
  3. What causes delay, in order of frequency
  4. Why very short timelines are a warning sign
  5. How to shorten the timeline without cutting quality
  6. What we do in the diagnosis

After price, this is the most common question, and the one that usually gets the vaguest answers. We are going to answer it with concrete timelines, say what happens inside each phase, and be explicit about what causes delay, which is almost always what nobody anticipates.

Before that, one clarification that changes how everything below reads: "ready" is not a single moment. There is the date the system goes into production with real users, and the date the system settles. They are different things, weeks apart, and most disappointment about timelines comes from conflating them.

Short answer, by project type

For a fixed scope, defined before work starts:

  • Single AI agent connected to one system: 6 to 10 weeks to production.
  • Custom CRM or ERP, first usable version: 8 to 12 weeks.
  • B2B portal or extranet for clients and suppliers: 8 to 14 weeks, depending on the number of user roles.
  • Internal AI platform with several departmental agents: 4 to 6 months, phased, with the first agent in production well before that.
  • Automation of one well scoped back-office process: 4 to 8 weeks.

These figures assume something that is not a given: that somebody on the client side is available to answer questions and decide. We come back to that, because it is the factor with the most weight on the real calendar.

What happens inside the timeline

A ten-week project splits, in practice, into four blocks, and the proportion between them surprises anyone expecting it to be mostly programming.

Weeks 1 to 2, definition. Walking the process with the people who run it today, surfacing the rules that exist but were never written down, and closing what falls inside and outside scope. It is the phase that most determines the end result and the one most often cut when somebody wants a shorter timeline. Cutting it does not save time, it postpones it.

Weeks 2 to 7, build and integration. This is the development itself, but also the unpredictable part: connecting to systems that already exist. If the ERP has a documented API, this is predictable work. If it does not, the effort can double without anything changing on the final screen, which is what we cover in the article on adding AI to the software your company already uses.

Weeks 6 to 9, validation against real usage. Not a demonstration. Putting the system in front of the people who will work with it every day and collecting what does not work. Cases always appear that nobody mentioned during definition, because they are too obvious to anyone who has been doing them for years.

Weeks 9 to 10, go-live and support. Data migration, training, and the period where the team watches what happens when the system meets the whole of reality at once.

After that, expect another four to six weeks of adjustment against real usage. It is not a sign of trouble, it is how any management system behaves: the first days of genuine use reveal more than any testing session.

What causes delay, in order of frequency

It is worth being direct here, because three of these four factors sit on the client side and all of them can be resolved in advance.

Access to third-party systems. The clear winner. An ERP maintained by an external vendor, a database connection that needs approval, a service account that takes three weeks to create. None of those timelines depend on the team doing the building, and all of them can be unblocked before the project starts.

Business rules that were never written down. Halfway through you discover there are three ways to calculate a commission depending on who you ask, and that nobody had noticed because everyone did it their own way. This is nobody's failing: it is normal in operations that grew without a system. But it needs a decision, and the decision needs someone with the authority to make it.

No single point of decision. A project that depends on a committee for every answer loses one to two weeks per cycle. A project with one person who knows the process and can decide moves at the pace of the development.

Scope growth mid-project. It almost always arrives with good intentions: while we are here, we might as well include this too. The healthy way to handle it is to record it and leave it for the next phase, with its own timeline and price. Absorbing it into the current scope is what turns ten weeks into five months.

Why very short timelines are a warning sign

If a proposal promises a management system in production in three weeks, there are two possible explanations and neither is good news.

Either the scope is far smaller than what was discussed, and you will find that out when you request the first change. Or the timeline counts development only and leaves out definition, integrations and validation. Those phases do not disappear by falling off the calendar: they reappear later as delay, and by then there is no budget left for them.

The same reasoning applies to price, incidentally. It is the same conversation from another angle, and the ranges are in the article on what it costs to implement AI in a company.

How to shorten the timeline without cutting quality

Three decisions genuinely shorten timelines, and none of them involve asking the team to work faster.

Reducing the scope of the first version is the most effective. A system that does half of what was imagined, well, in production in eight weeks, produces learning the complete version would not produce in twenty. The second phase then costs less, because by then you know what actually matters.

Preparing access before kick-off saves entire weeks. If the project will touch a system managed by a third party, that conversation can start today, before there is even a contract.

Naming one person with decision-making authority, and freeing up their time, is what separates a project that moves from a project that waits.

What we do in the diagnosis

We look at the concrete process, at the systems already in place and at who will use the result, and come back with a calendar of phases, dates and what is needed from each side at every step. If the timeline that makes sense is not compatible with what you need, we say so before starting.

The diagnosis is free, carries no commitment, and we answer contact requests within 48 business hours. You can talk to us or see how we approach custom software development.

Frequently asked questions

How long does it take to build a custom CRM or ERP?

For a fixed, well defined scope, 8 to 12 weeks from kick-off to a first version in production with real users. Systems covering several areas of the company at once easily pass six months, which is why we recommend phasing them.

And an AI agent connected to our systems?

Typically 6 to 10 weeks for a single process in production, including integration, validation and support. The timeline depends far more on how the data is reached than on the complexity of the AI itself.

Why do some vendors promise much shorter timelines?

Usually because they are counting development time only, leaving out rule definition, third-party integrations and user validation. Those phases do not disappear by being left off the calendar: they show up later, as delay.

What delays a software project the most?

In order of frequency: waiting on access and credentials for systems managed by third parties, deciding business rules that had never been written down, and the absence of someone on the client side with authority to close decisions.

Can we have something working before the full timeline is done?

Yes, and that is how we work. There is always a usable version before the complete one, typically around the middle of the calendar, so that validation happens against real usage rather than a presentation.

Neumotik

Ready to implement in your company?

We develop custom software that solves exactly the problems described in this article. Free diagnosis, no commitment.