- Platform
- Web App
- Duration
- 14 weeks
- Industry
- Enterprise, Retail, Consumers
- Read time
- 6 min
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.
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.
before & after
The campaign constraint and the delivery decision
- 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
- 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
- 01
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.
- 02
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.
- 03
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.
outcomes
What we achieved
Source: AldiFest project delivery record, first seven days of the campaign.
Source: AldiFest project delivery record, first seven days of the campaign.
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.
IrelandIncredibly simple and easy to use app. Exactly what we were looking for.
Planning a receipt campaign with a fixed launch date and measurable participation?
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.
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.
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.
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.
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.
Engagement
How we worked together
- 01Weeks 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. - 02Ongoing
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. - 03Ongoing
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. - 04Final
Handover and warranty
Full code handover with deployment runbooks and documentation. Thirty-day warranty period for production issues at no extra cost.
stack
Technology used for the campaign
- 01Next.jsNext.js supported the responsive shopper web experience and let the campaign run without requiring an app-store install before a receipt could be submitted.
- 02AWS LambdaLambda 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.
- 03PostgreSQLThe campaign needed relational records for shoppers, receipts, campaigns, and entries. PostgreSQL kept those product relationships in one transactional store.
- 04VercelVercel hosted the Next.js application and supported repeat deployments as the annual campaign content and configuration changed.
Questions retail campaign owners ask before a receipt-app build
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.
