5,000 receipts processed in the first week

RaftLabs built AldiFest for Aldi Ireland through BrandFire: a 14-week receipt campaign that turned qualifying purchases into competition entries and gave the campaign team a measurable digital participation flow.

shopper signups in the first week
2,000+
receipts processed in the first week
5,000
from scoped campaign to delivery
14 weeks

Short answer

RaftLabs built AldiFest, a receipt-based campaign web app for Aldi Ireland delivered through BrandFire, in 14 weeks. Shoppers uploaded receipts from qualifying purchases to receive competition entries. Project records show 2,000+ signups and 5,000 receipts in week one. The campaign team also reported 2x purchase frequency and 25% higher average purchase value, without a retained public measurement method.

The situation

Aldi Ireland wanted its festival campaign to produce a measurable action after a shopper saw the promotion. The action had to stay simple: make a qualifying purchase, upload the receipt, and receive an entry into the AldiFest competition.

RaftLabs built the campaign web app through BrandFire in 14 weeks. Project records show 2,000+ shopper signups and 5,000 receipts processed during the first week. The campaign team also reported that purchase frequency doubled among participants and average purchase value rose by 25%. Those two uplift figures are useful context, but the retained public case record does not include the cohort definition, comparison period, or analytics method. We therefore present them as client-reported outcomes rather than independently verified measurements.

The case is most useful for retail teams planning a seasonal receipt campaign. It shows the value of one clear mechanic, a bounded first release, and source labels that separate participation counts from commercial lift claims.

AldiFest receipt upload and competition entry web app for Aldi Ireland

Before and after

The campaign constraint and the delivery decision

Before
  • The festival promotion needed a digital participation path connected to a real purchase
  • A fixed campaign window made launch readiness more important than a broad loyalty feature list
  • Receipt submissions, shopper records, and competition entries needed one consistent operating flow
  • The team needed campaign participation data it could review while the promotion was live
After
  • Shoppers could register, upload a receipt from a qualifying purchase over €25, and receive a competition entry
  • The campaign team could manage shopper and receipt records from one web application
  • Weekly competition activity could be operated from recorded entries instead of separate spreadsheets and inboxes
  • The first release stayed focused on the AldiFest mechanic, leaving wider points, tiers, and POS loyalty outside the launch scope

What the first release had to get right

  • Design for a fixed launch date and a short demand spike

    A seasonal campaign cannot quietly slip by several weeks. Marketing, prizes, media, and store activity converge on the announced window. We kept the release centred on registration, receipt submission, entry creation, campaign administration, and reporting. A wider loyalty wallet or multi-brand rules engine would have increased schedule risk without helping the first campaign prove participation.

    The system used Next.js for the shopper experience and AWS Lambda for campaign functions. That serverless shape suited a campaign with a busy launch period and long quieter intervals. We do not publish a tested concurrency ceiling for AldiFest, so this case does not claim one.

  • Keep a purchase, a receipt, and an entry traceable

    The core product rule was easy to explain to a shopper: an eligible receipt creates an entry. The harder work was keeping the records behind that rule consistent. The application had to associate the submission with the shopper and campaign, preserve its state, and give the campaign team a manageable review path.

    PostgreSQL stored the transactional records. That choice mattered because shopper accounts, receipt records, and competition entries belong together. The case record supports the shipped workflow and first-week counts; it does not document a fraud-detection model or an automated OCR accuracy rate, so we do not claim either.

  • Measure participation without overstating causation

    The campaign produced direct participation measures: registrations and receipts processed. Commercial measures such as purchase frequency and basket value require a defined baseline, time window, and participant cohort. The client reported positive movement in both, but the public project record does not retain the method.

    For a new campaign, we would agree the measurement plan before launch: qualifying cohort, comparison cohort, baseline period, exclusions, and the source system for each metric. That makes the outcome easier for marketing, finance, and analytics teams to trust later.

Proof

What we achieved

shopper signups in the first week
2,000+
Source: AldiFest project delivery record, first seven days of the campaign.
receipts processed in the first week
5,000
Source: AldiFest project delivery record, first seven days of the campaign.
from scoped campaign to delivery
14 weeks
Source: RaftLabs delivery record for the AldiFest build.

What clients say

What BrandFire said about the delivery

Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.

Testimonial 1 of 1: Nuala C.

Nuala C.

Director, BrandFire

Ireland flagIreland

Incredibly simple and easy to use app. Exactly what we were looking for.

2,000+
shopper signups recorded in the first week
5,000
receipts processed in the first week

the build

The product decisions behind the campaign

The first release stayed anchored to one loop: qualifying purchase, receipt submission, recorded entry, campaign operation. That focus made the product understandable to shoppers and kept delivery tied to the campaign deadline.

  1. One shopper action carried the campaign

    Shoppers registered and uploaded a receipt from an Aldi purchase over €25. Each accepted receipt created a competition entry for prizes that included Electric Picnic tickets and €100 Aldi gift cards. The receipt mechanic connected an in-store purchase with a digital campaign action without requiring a native mobile app.

    Receipt upload screen for the AldiFest competition campaign
  2. The data model followed the operating rule

    The product kept shopper, receipt, campaign, and entry records connected. This was more useful than treating uploads as a folder of images because the campaign team needed to operate the promotion from structured records. PostgreSQL provided the transactional store for those relationships and the history required by the application workflow.

    Campaign entry records for the AldiFest retail loyalty web app
  3. The admin surface served the campaign team

    The operating team needed to review campaign activity, manage entries, and work from the same records the shopper flow created. We treated campaign administration as part of the product, not as a post-launch spreadsheet process. The public case record does not expose the internal review rules, so buyers should not infer a specific fraud or compliance control from this page.

    AldiFest campaign administration and shopper entry status
  4. Repeat use mattered more than adding unrelated loyalty mechanics

    RaftLabs has delivered the AldiFest campaign platform annually since 2022. That continued use is the clearest durability signal in the case. Each cycle can retain the proven campaign flow while dates, content, and prizes change. A retailer that needs an always-on points, tier, or cashback program should treat that as a separate product decision and review our loyalty program development service.

    AldiFest retail campaign reporting interface

Engagement

How we worked together

Weeks 1–2

Discovery and scoping

We map the problem before writing code. Two weeks of technical audit, stakeholder interviews, and prototype, so both teams align on scope and risk before sprint one.

  • Ongoing

    Two-week Agile sprints

    Each sprint ends with working software, not a status update. You review a real build, request changes, and approve before we move forward. No surprises at handover.

  • Ongoing

    Daily async updates

    Slack for daily progress, Asana for task visibility, weekly video calls for decisions. You have full visibility without needing to attend every meeting.

  • Final

    Handover and warranty

    Full code handover with deployment runbooks and documentation. Thirty-day warranty period for production issues at no extra cost.

How it runs

Next.js
Next.js supported the responsive shopper web experience and let the campaign run without requiring an app-store install before a receipt could be submitted.
AWS Lambda
Lambda matched the burst-and-idle shape of a seasonal campaign. The public project record does not publish a load-test ceiling, so the case limits the claim to the architecture choice.
PostgreSQL
The campaign needed relational records for shoppers, receipts, campaigns, and entries. PostgreSQL kept those product relationships in one transactional store.
Vercel
Vercel hosted the Next.js application and supported repeat deployments as the annual campaign content and configuration changed.

Common questions

The project record directly states 2,000+ shopper signups and 5,000 receipts processed in the first week, a 14-week delivery, and annual delivery since 2022. The campaign team reported 2x purchase frequency and 25% higher average purchase value. The public record does not retain the cohort, baseline, or analytics method for those uplift figures, so we label them as client-reported.

Define the qualifying purchase rule, campaign dates, entry rule, prize and draw process, receipt review policy, shopper support path, consent language, retention period, and outcome measurement plan. Decide who can change each rule after launch. AldiFest kept the customer mechanic narrow: a purchase over €25, a receipt submission, and a competition entry.

That policy should be agreed before implementation. A production design can retain a receipt fingerprint, retailer and transaction identifiers when available, shopper history, review status, and an operator decision trail. The right checks depend on receipt quality, POS access, campaign rules, and acceptable false positives. This case does not claim a specific AldiFest fraud model or OCR accuracy rate.

Yes, if traffic shape and failure handling are designed before launch. AldiFest used AWS Lambda for campaign functions, which suited a burst-and-idle workload. A new project should still define expected signup and upload rates, load-test the complete receipt path, monitor queues and errors, and keep an operator fallback. We do not publish a tested AldiFest concurrency ceiling.

RaftLabs delivered the scoped AldiFest campaign in 14 weeks. That record covers one retailer, one qualifying-purchase mechanic, receipt submission, competition entries, campaign administration, and reporting. Multi-retailer tenancy, POS integrations, always-on points, partner rewards, or complex fraud review would change the scope. Use our pricing framework to understand how product complexity affects a fixed quote.

Receipt uploads can support a time-bound campaign when a POS integration is unavailable or too slow for the launch window. A POS connection can reduce shopper effort and give cleaner transaction data, but it adds retailer-system dependencies, security review, and integration testing. Choose from the campaign deadline, available identifiers, fraud risk, and the long-term loyalty plan.

It is proof of a focused retail receipt campaign, including shopper participation, receipt processing, competition entries, and repeat annual delivery. It does not by itself prove points-ledger, tier, coalition, or POS loyalty work. Buyers planning those capabilities should review the broader retail loyalty program service and scope the evidence required for their use case.

Work with us

Recognise this problem in your business?

Tell us what's broken. We'll diagnose it and show you exactly what to fix first, before you commit to anything.

  • Scope and cost agreed before work starts. No surprises. No obligation.
  • Working prototype within 3 weeks of kickoff.
  • Pay by milestone. You see progress before each invoice.
  • 60-day post-launch warranty. Bug fixes, UI tweaks, and deployment support. No retainer.
  • All conversations are NDA-protected.