What a Year of Working With Us Looks Like: 15 Months on a Live Stock Alert System

Most case studies end at launch. This one starts there.

In July 2025 Jardar Tveit, CEO of Korriban Libraries in Norway, found us on Fiverr. He wanted something small: an AI agent that checks the stock market every day and emails him when a company's share price falls hard. Fifteen months later that email still lands in his inbox every day. Around it, the project has grown a full price-history database, a search tool built to his own criteria, a SQL playground and a plain-language manual.

We wrote this one differently. Everything below is reconstructed from the project's email threads, including the edge cases any system meets when it runs on live market data every day. If you are deciding whether to hire an AI development partner, the question that matters is not "can they build it?" It is "what happens in month four, when something new comes up and the invoice has already been paid?" This is our answer, with receipts.

Who the client is and what he wanted

Jardar is not a developer. He is an investor who looks for companies whose share price has collapsed in a day and then watches whether they recover. Doing that by hand means scanning thousands of tickers every evening. He wanted that scan done for him, and the results in his inbox.

His first brief, from our kickoff call on 22 July 2025, fitted in a few lines:

• Watch the major stock exchanges every day.
• Flag any stock that drops more than a set threshold (he started at 50%) in one day.
• Email the list at 18:00 his time.

He had first wanted the alerts on WhatsApp, then decided email was simpler. That small decision set the tone for the whole project: start with the plain version, add to it once it works.

Month one: a small, fixed-price build

We scoped it as a fixed-price build, half paid up front and half on delivery. No retainer, no discovery phase billed separately. For a first project with a new client, that matters more than the price: he could find out what working with us was like before committing to anything bigger.

Everything ran on his accounts. He created the AWS account, added us to his OpenAI project, and set up the data source. We asked for the access we needed and nothing more, and when the AWS permissions blocked the setup we said so plainly and he granted administrator access on a call. The result: on the day the work ended, there was nothing to migrate, nothing locked in our infrastructure, and nothing he needed us for unless he wanted us.

Seven days after kickoff we sent him the first sample alert: five stocks that had dropped more than 50% that day, with the previous close, current price, intraday low and current status for each. His reply came the same day: "This looks promising!" Then a change request. He wanted the explanations moved out of every row into a single glossary at the bottom, so he could scan the numbers fast. He sent a sample of the exact layout. We built it his way.

Two more requests followed in the first fortnight, and both are worth a line because they show how real requirements surface:

1. "Nothing to report" emails. After a quiet day he emailed to ask whether the system was broken. It was not; nothing had met the threshold. So we added a daily email saying exactly that. Silence is ambiguous. A "No alerts today" message is not.
2. More exchanges. He listed seven he wanted covered, including Oslo, Stockholm, Copenhagen and Helsinki. We told him the truth: the large exchanges were already covered by the data feed, but the Nordic ones had no stable, unified APIs and would mean custom pipelines, real time and real cost. He decided to keep to the large ones for now. Saying "this is not worth it yet" cost us billable work. It also earned a client who believed us later.

Every stage went through QA before handover and was signed off by Jardar himself. By 8 August he wrote: "Happy news! The program is working." On 15 August we sent him the full code repository for his records. His reply: "The alerts are working as intended. I am very happy about that."

How the system fits together

Jardar asked us later for "a single line diagram" that explains what each part does, "as simple as possible". This is that diagram, in the same spirit.

Every box in that diagram sits in an account the client owns. That was a deliberate choice, and it is the one we would make again for any client.

Months two to four: from an alert to a research tool

Once the alerts were trusted, Jardar sent a roadmap document for what he really wanted: a way to study what happens after a crash. That became the second paid stage.

His spec, in his own email of 23 September 2025, listed the data points to capture for every stock that fell below the threshold: the ticker, market cap at the low, the company's age, how long it had been listed, its industry, a daily chart for a year after the drop, and a flag if it recovered more than a set percentage within that year. Then the part that turns a database into a tool:

"I want it to work in the way that I can set the parameters for the type of stock behaviours I want, and then hit search."

He wanted to run that search across 10 to 20 years of history. In October he subscribed to a historical data provider, and on 3 November 2025 we confirmed the database held price data for every stock since it was first listed, with the search deployed in the web app. Like the first stage, it was tested and signed off before the second invoice. He paid it on 16 November and wrote: "Thank you for the nice work."

That is where a lot of agency relationships quietly end. For us it was where the partnership started.

Months four to nine: the part most case studies leave out

Between September 2025 and April 2026, Jardar sent ten separate requests after launch: new ideas, format preferences, questions and edge cases from live market data. Here they are, in order:

Nothing after the second stage closed in November 2025 was invoiced. We also proposed one thing he did not ask for: in January 2026 we suggested a SQL playground inside the web app, read-only, so he could query his own database without waiting for us. He said yes, we built it, and sent a starter document of example queries with it. The best support request is the one the client never has to send.

When the market data got strange

A system that reads the whole stock market every day for 15 months will meet data nobody planned for. None of these came from the build, which had been tested and signed off. They came from the outside world, and handling them quickly is what keeps a client trusting the alerts.

The 336-stock day. On 5 December 2025, a volatile day, the system identified 336 stocks. An email that long would not send, so the alert carried 14. Jardar asked about the gap, we explained it in writing that week, and retuned the threshold so alerts stay short and readable even on extreme days.

The legacy ticker. In January 2026 one stock, SDM, kept appearing in every alert with the same price. Jardar wondered whether it was old data from the provider. It was: a legacy record in the provider's history. We traced it the same day and added a guard so stale records cannot resurface. His reply: "Now the issue is solved."

Zero-price readings. In March 2026 some alerts listed companies as down 100% when they clearly were not. The market feed was occasionally sending a current price of zero, which the maths reads as a total wipeout. We got on a call, Jardar shared annotated screenshots of exactly which readings looked wrong, and we added a filter that discards zero-price data before any alert goes out. The alert emails we have checked since carry real prices in every field.

Notice the pattern. Each one started with live data behaving in a way no test set would show, and each was handled with the client rather than around him. A client who knows his own market, and a team that listens to his reports and explains causes in plain words, is how a system gets more robust every month instead of more fragile.

How a support request actually runs

Every one of the ten requests followed the same shape. He reports, usually with a screenshot. We acknowledge it the same day, often within minutes. We reproduce it on the live system, fix it, and tell him what it was in plain words. He confirms.

None of this is clever engineering. It is the steady discipline of answering every email, explaining every cause in plain words, and closing the loop in writing. It is also the thing buyers tell us they could not get from their last vendor.

Where it is now

As of October 2026:

• The alert email still arrives every day, including the "No alerts today" ones, with the abbreviations and glossary in the format he designed in the first week.
• The historical database and search are live in the web app, with the SQL playground for his own queries.
• He owns the AWS account, the OpenAI account, the database and the code.
• In March 2026 he asked for an access token so his own AI agent could use the app. A system we built to send one email is becoming a data source for another AI.
• A further stage, alerts across the Shanghai and German markets, is scoped and quoted. He chose to wait, and we were happy to. There is no pressure in a relationship like this, only an open door.

In November 2025 he left a review on Clutch. One line from it is now on our homepage: "They were very deliberate and straight to the point."

What this means if you are hiring an AI partner

You can learn more about a vendor from month six than from the demo. Before you sign with anyone, including us, ask for three things:

1. Who owns the accounts? If the system runs on the vendor's cloud and their API keys, you are renting it. Everything here runs on the client's own accounts. Our guide to choosing an AI automation company covers the other questions that separate builders from resellers.
2. What happens after launch? Ask to see a real support thread, not a support policy. We include two months of free support and maintenance with every project, and this client shows what it looks like when we keep going past that. If you are weighing an agency against a hire, the cost comparison is here.
3. Will they tell you no? The Nordic exchanges answer cost us work and saved him money. A partner who never says "not yet" is selling, not advising. Our piece on how to tell if an AI agency can actually build it goes deeper on this.

For the engineering side of a market-data platform like this one, see our AI stock analysis platform case study. For another fast, tightly scoped build, see how we turned 6,000+ LinkedIn applicants into a clean hiring pipeline in about two weeks. And if you want to know what a first build like this would cost for your own workflow, our AI automation cost guide is the honest starting point.

Frequently Asked Questions

How did this project start?

The client found us on Fiverr in July 2025. After one kickoff call we scoped a small, fixed-price first build: a daily stock-drop alert email. He paid half up front and half on delivery, and the first sample alert reached him seven days after the call.

Who owns the system, the code and the data?

The client does. It runs on his own AWS and OpenAI accounts, the database sits in his AWS account, and we handed over the full code repository in August 2025, a month after kickoff. If we disappeared tomorrow, nothing would stop working.

Is support included after launch?

Every project includes two months of free support and maintenance. On this project we kept supporting Jardar well past that, without invoicing, because a system the client relies on every day deserves to stay sharp. New features, like additional stock markets, are scoped and quoted separately, and the client decides if and when.

How do you handle problems that come from outside data?

We treat them as part of the job. Live market feeds sometimes send stale records or zero prices. When Jardar spotted readings that looked wrong, we got on a call, used his annotated screenshots to pinpoint them, and added filters so that kind of data never reaches an alert again.

Can a non-technical client really understand a system like this?

Yes, if the people who built it explain it properly. The client asked for a diagram "as simple as possible", so we wrote a plain-language document covering what each part does and where the data comes from. Later we added a read-only SQL playground with example queries, so he could explore his own data directly.

Do you only take on large projects?

No. This one started as a single alert email. Starting small lets a client find out how we work before committing to anything bigger, and most of our long-running work began exactly that way.