How TerraBlick turns unstructured shopping receipts into explainable sustainability insights and practical reminders—and the decisions made along the way.
Project summary
01 / The problem
People increasingly want to make more sustainable choices, yet understanding the impact of everyday consumption remains difficult.
Many carbon footprint tools rely on generic questionnaires. They ask people to remember and summarize their habits, which creates distance between the answer and what actually happens.
Shopping receipts offered a different starting point: instead of asking people what they think they buy, why not learn from what they actually purchase?
Starting observation
A receipt is imperfect, but it is concrete. That single observation became the starting point for TerraBlick.
Input
Abbreviated, multilingual text with inconsistent layouts and imperfect scans.
Missing layer
No stable product identity connects a single purchase to longer-term behavior.
Needed output
Useful guidance that communicates uncertainty instead of hiding it.
“The challenge was never reading receipts. The challenge was deciding what could be concluded from them with confidence.”
02 / Product philosophy
TerraBlick was never intended to punish people for what they buy.
Sustainability products often communicate through guilt. TerraBlick deliberately takes a different approach: reward positive decisions, make progress visible, and encourage gradual change without pretending that consumption is simple.
Explain the signal and its limits.
Recognize better choices and progress.
Keep the user in control of decisions.
The application should inform rather than judge. That principle affects the reward model, the language, and how uncertainty is presented.
03 / System shape
The architecture mirrors the uncertainty of the problem by separating extraction, interpretation, normalization, and analysis into distinct stages.
Validate type, size, ownership
Textract returns document text
Structured JSON identifies products
Aliases and family rules converge
Receipt and item records are stored
Insights and reminders are computed
Runtime boundaries
HIGH LEVELWhy layered services?
External providers, persistence, and AI models are expected to evolve over time. The business rules should remain stable despite those changes.
Responsibilities are separated across controllers, services, repositories, and domain logic to keep the system maintainable and easier to evolve.
04 / Key decisions
Each decision starts with a constraint, not a framework preference.
Problem
Receipts are noisy, multilingual documents. Asking one model to read pixels and infer sustainability made failures hard to locate.
Decision
Use OCR for document extraction, then pass bounded text into a separate interpretation step.
Outcome
Each stage can fail, retry, and evolve independently. OCR quality and model output can be inspected separately.
Problem
The same product appears under store abbreviations, languages, and OCR variants. Raw strings fragment purchase history.
Decision
Resolve exact aliases first, fuzzy aliases second, and product-family rules as a conservative fallback.
Outcome
Recurring products become a usable signal without pretending every ambiguous line can be classified.
Problem
A shopping reminder needs to be predictable and correctable. Opaque recommendations are difficult to trust or test.
Decision
Model intervals, variance, quantity, trip horizon, and user dismissals with a pure rules engine.
Outcome
Every result is traceable to stored behavior, and user feedback overrides the algorithm immediately.
05 / Architecture decisions
The technology stack was chosen to match the problem: document processing, authenticated user data, evolving business rules, and relational history.
Why
Receipt files needed durable object storage and document OCR. Keeping both capabilities within AWS reduced integration boundaries and made asynchronous PDF processing possible.
Tradeoff
The pipeline now depends on AWS APIs and requires explicit cleanup, permissions, and failure handling.
Why
User-scoped receipt history requires real identity and token verification. Cognito provided managed sign-up, sessions, and JWTs without building an authentication service.
Tradeoff
Managed auth lowers security surface area, but adds SDK complexity and provider-specific configuration.
Why
As business rules grew, they needed clearer boundaries than large route handlers could provide. Controllers, services, repositories, and pure engines make responsibilities explicit.
Tradeoff
It introduces more structure and files, so migration from existing Next.js routes is deliberately incremental.
Why
Receipts, line items, users, aliases, dismissals, and purchase history are relational. SQL supports ownership checks, aggregation, and traceable historical queries well.
Tradeoff
Schema evolution and normalization require care, but that discipline is useful for data the product must explain.
06 / Product normalization
A reminder cannot learn that “HAFER DRINK,” “Oatly Barista,” and a truncated OCR line may describe the same product family unless identity is resolved first.
The system prioritizes precision, then degrades gracefully. Unknown is a valid result; a confident wrong match is more damaging than an honest gap.
// ordered resolution strategy
07 / UX & interface
Early flows were explored in UX Pilot and refined in Figma before implementation. The goal was not visual novelty; it was making a technically uncertain process feel understandable.
The interface prioritizes clear language, visible processing states, accessibility, and explicit communication of uncertainty.
Problem
OCR, scoring, and predictions can easily overwhelm a user with implementation detail.
Decision
Reveal the result in stages and use familiar product language instead of model terminology.
Implementation
Figma-defined flows become responsive React views with accessible states and explicit uncertainty labels.
Outcome
The product communicates what happened, what it means, and what the user can do next.
08 / Scaling & evolution
The goal is not to predict the future, but to ensure today's assumptions can evolve without rewriting the system.
API instances can scale horizontally because workflow state lives in PostgreSQL and external services.
Reminder rules can be tested across edge cases without a database, framework, or network.
OCR and model integrations are stages in a pipeline rather than domain concepts.
Normalized receipt items create a durable base for new insights without re-reading every source file.
09 / Roadmap
Future directions for TerraBlick
Turn receipts into sustainability insights and personalized shopping recommendations using OCR, AI, and product normalization.
Support electricity, gas, and water bills to build a broader view of household consumption.
Add public transport, fuel purchases, and travel data alongside household sustainability signals.
Unify shopping, utilities, and mobility in one dashboard with richer long-term analytics.
Help people understand patterns, discover practical improvements, and make more sustainable decisions over time.
Direction without dates: every milestone remains subject to evidence, privacy review, and validation.
10 / Honest constraints
A useful case study should include the edges of the system, not only its center.
01
Current factors are heuristic, not a scientific lifecycle assessment dataset. Regional and store-specific variation is not modeled.
02
The system observes purchases, not pantry stock, consumption, travel, guests, or sudden changes in routine.
03
Long-tail products remain unknown until evidence supports an alias or family rule. This protects downstream behavior from false matches.
04
Some workflows still live in Next.js route handlers while domain services move toward the layered NestJS API. Compatibility matters during that transition.
11 / Reflection
Building TerraBlick required much more than implementing software. It involved product thinking, cloud architecture, AI integration, system design, and continuous iteration.
TerraBlick continues to evolve, but its core principle remains unchanged: make sustainability understandable through transparent engineering rather than opaque automation.
Engineering is ultimately about making complex systems understandable—for both computers and people.
Visit TerraBlick