A small or medium business? Stop buying six-month projects

Contents

1. Why a six-month project used to be a reasonable decision
2. 2026 by date: what changed while the projects were being built
3. What research says about long projects
4. A self-check: five questions for a project you have already bought
5. When a big project is exactly the right thing
6. The shorter road: live first, custom later
7. What WhaleBiz does today
8. Frequently Asked Questions

Which part of the AI or automation project you bought this year answers real customers today? Not in a test environment, not in a Zoom demo, but in front of people who write to the business and wait for a reply. If the answer is "not yet", you are not alone, and most likely nobody cheated you either. The problem is the model itself: a fixed-scope project, specified in one month and delivered six months later, in a field where the rules change every month. For a small or medium business that means paying a lot, waiting a long time and receiving a system designed against rules that no longer apply. This article explains why that happens, what research says about long projects, how to check a project you have already bought, and what the shorter road looks like.

Why a six-month project used to be a reasonable decision

The model is familiar to anyone who has ever bought software: specification, a requirements document, a fixed quote, build, testing, handover. It was born in a world where the ground stood still. An accounting system, a brochure website, internal stock software: what was specified in January was still right in July, because the rules around it barely moved. A fixed scope gave the client certainty on price and the vendor certainty on the work, and that was fair to both sides.

With AI and platform integrations it works differently. A system that answers customers on WhatsApp, posts to LinkedIn or uploads videos to YouTube does not live alone. It relies on other companies' interfaces (APIs), on their usage policies and on their price lists, and those move every month. The models themselves and the tools for building agents also change at a pace business software has never seen. Every month between specification and handover is a month in which some of the specification's assumptions go stale.

What gets delivered in the end is not a new system. It is a system born old: legacy from day one, and hard to update, because under a project contract every update is a change request, a quote and another wait. And if the vendor has already moved on to the next client, there is nobody to call.

2026 by date: what changed while the projects were being built

This is not a general claim. Here is what happened this year on the platforms alone that a small Israeli business touches every day, as of 25 October 2026:

We covered the January rule in detail in what an AI agent on WhatsApp may do in 2026, and the three billing changes in WhatsApp's new pricing: what is paid and from when. The prices there are Meta's, not ours. The YouTube change is documented on the official upload API page.

The last row is the cleanest example. LinkedIn releases a new version of its Marketing API every month and supports each version "for a minimum of one year" before it is switched off. Version 202510 was already sunset on 15 October, and on 16 November 202511, released in November 2025, goes the same way. LinkedIn also says plainly that it expects an integration to be maintained at least once a year. In practice: an integration built last November that nobody has touched since will stop working on 16 November. Not because anyone built it badly, but because that is what happens to code with no owner.

Now take a project specified in January and delivered in July. While it was being built, the WhatsApp rate card changed, and in the three months after handover came two more billing changes and a YouTube change. It was designed against at least three sets of rules that no longer hold, and if nobody is responsible for updating it, it stays designed against them.

What research says about long projects

There is no study of exactly a six-month AI project in a small Israeli business. There are a few large studies that show the mechanism, and they are worth reading with their caveats.

The longer the project, the bigger the risk. A study by McKinsey with the University of Oxford of more than 5,400 IT projects found that large projects ran on average 45% over budget and 7% over time and delivered 56% less value than predicted, and that every extra year of a project added about 15% to the cost overrun. The study is from 2012 and covers projects above $15 million, so it says nothing about a small business in 2026. It does show the direction: time itself is a risk factor.

Buying from a specialist works better than building alone, and faster in mid-sized firms. A much-quoted 2025 MIT report on generative AI in organisations claimed that only about 5% of pilots reached a measurable impact on profit. That headline is disputed, because the report rests on interviews, a survey and an analysis of a few hundred public deployments rather than a large sample. Two other findings in it are more relevant: solutions bought from specialised vendors or built with partners succeeded about 67% of the time, while internal builds succeeded only about a third as often, and mid-market companies moved from pilot to full rollout in about 90 days, against about nine months in large enterprises.

A large share of agent projects will not survive. Gartner forecasts that more than 40% of agentic AI projects will be cancelled by the end of 2027, because of rising costs, unclear business value and weak risk controls. That is a forecast, not a measurement.

None of these studies says "do not build". They say that the longer the road and the less clear the goal, the more likely the project ends without a result.

A self-check: five questions for a project you have already bought

Say you paid tens of thousands of shekels at the start of the year and more than six months have passed. These questions take ten minutes, and they are not an accusation against the vendor. They check the situation, not the people.

1. Which part answers real customers today?

Not a demo and not a test environment, but one message from a real customer that got a reply from the system. If there is none, everything else is a plan.

2. Who updates it when Meta, Google or LinkedIn change the rules next month?

Ask for the name of a person or a team, not "we will handle it". If the answer is a new quote for every change, know that the changes will come anyway, as the table above shows.

3. Which API versions does it run on, and when do they expire?

A serious vendor can answer within a day. If nobody knows, nobody will know before the integration stops working either.

4. Can you leave with your data?

Conversations, leads, contacts: which account they sit in, and how you export them if you decide to move. Data you cannot export makes every future decision more expensive.

5. What goes live in the next 30 days, and what will it measure?

Not "the next phase", but one action with a date and a number you can check: response time, enquiries closed with a complete record, appointments booked.

If the answers are "nothing yet", "nobody", "we don't know" and "not sure", it is time to change the scope, not to wait another quarter. Changing the scope means picking one action the business needs today, for example answering evening enquiries that come from the ads, putting it live in front of customers, and leaving the rest for later steps. Money already paid does not come back by waiting longer.

When a big project is exactly the right thing

It is important to say this clearly: there are organisations where a multi-year programme is a necessity, not a mistake. A bank, Bituach Leumi (the National Insurance Institute), the Ministry of Defense, government ministries, very large corporations. They have dozens of systems, regulation, security requirements and hundreds of users, and a quick ready-made solution there would be irresponsible.

A mid-sized business also has needs that really are projects: a deep integration into an internal system the agent must write to directly, sensitive data that requires separation and restricted permissions, several teams or branches with different processes. And honestly, the other direction has a cost too. A ready product can be the wrong fit, and a cheap box that does not match the process wastes money just as a long project does. Buying fast without defining a goal fails just as well: a RAND study found that the leading cause of AI project failure is a business problem that was not properly understood, not the model. So before choosing a tool or a vendor, it pays to define which actions the AI will take and at what moment.

The answer, then, is not "never a project". It is small, defined steps, on top of something that already works, with a goal you can measure.

The shorter road: live first, custom later

This is what it looks like in practice in a small or medium business:

1. One action, one channel, real customers, within weeks. For example an agent that answers on WhatsApp, qualifies and hands a hot lead to a person with a summary of the conversation.
2. On a platform someone else keeps current. Updating API versions and responding to policy changes are part of the service, not a new project every time.
3. A month of measurement. What customers ask, where they stop, how many enquiries turn into an appointment or a call.
4. Custom development in small steps. An integration with an internal system, a unique process, another channel. Each step is priced before work starts, and each step has its own goal.

The difference from the long project is not that there is no development, but the order. If you have not yet signed with any vendor, we put together five questions to ask before you sign a proposal, and they complement the self-check above.

What WhaleBiz does today

We build too: integrations with clients' systems, custom processes, websites. WhaleBiz is an AI startup that wrote and runs its own sales system, with AI agents and a built-in CRM, so every client starts with us from something that is already running.

• A ready plan goes live in business days, not months. The setup time of each plan is listed in the current price list on the site, and it is counted from the moment we have received all your materials.
• The subscription starts on the day the agent goes live, so the first month you pay for is a month of a product that already works. The setup fee is paid in one payment before work starts, and it is non-refundable.
• The platform is ours, and we keep it current. New API versions and policy changes at Meta or LinkedIn are our routine work, not a new project of yours. Fixing faults is free and unlimited.
• The plans differ in capabilities. Start is a website widget or Telegram, with no WhatsApp and no appointment booking. WhatsApp, appointment booking and media sending start on Standard. Instagram and Facebook, in-chat payments and several agents are on Business.
• What does not fit the box is custom development. A discovery call, architecture, a statement of work, and a fixed project price approved before work starts. The details are on the page custom AI solutions development.

The agent handles most conversations, and when a person is needed it hands the conversation to your team with the full context.

Frequently Asked Questions

How long should AI implementation take in a small business?

The first part that works with real customers should go live within weeks, not months. Deep integrations and special processes are added later, in steps. With us the setup time is a plan parameter, it is listed on the pricing page, and it is counted from the moment we have received all the materials.

We already paid for a project that is running late. What do we do?

Not necessarily cancel. Go through the five questions in this article, ask the vendor for one action that goes live within 30 days, and make sure the data can be exported. If there are no clear answers, change the scope now rather than waiting another quarter.

Is a custom project always a mistake for a small business?

No. A deep integration into an internal system, sensitive data or several teams with different processes are good reasons for a project. It is just worth building it in small, priced steps, on top of a system that already works.

What does it mean when an API version is sunset?

Platforms like LinkedIn release new versions of their interface and switch off old versions on a date announced in advance. An integration that was not updated to a newer version gets an error and simply stops working. That is why every system connected to platforms needs someone responsible for updating it.

How does WhaleBiz price custom development?

After a discovery call and architecture planning, we write a statement of work with a fixed project price, approved before work starts. Before that it is worth checking whether a ready plan already covers the need, because it is almost always faster and cheaper.