Mostt — Case Study

BI and analytics layer for Mostt, the family-investing app that lets parents save and invest for their children.

Summary

Mostt is a US-based, AI-assisted investment app aimed at parents — recurring contributions, brand-partner rewards on everyday spend, and a long-term "save and invest for your children" frame. topsweteam built the BI and analytics layer behind the product. One fullstack engineer delivered a ClickHouse + Metabase + SQL stack that gives the team operational and product visibility into how the app is being used and where the financials sit. Implementation is complete.

• Client: Mostt (mostt.co)
• Industry: Fintech / Consumer investing
• Engagement: BI module — 1 fullstack engineer
• Timeline: 19 Oct 2025 – 1 Mar 2026 (~4.5 months)
• Team: 1 fullstack engineer
• Status: Implemented

Challenge

A consumer investing app has two sets of analytical questions to answer at once: product questions (which features get used, where users drop off, which acquisition channels actually convert) and money questions (how much is being invested, how the portfolios are moving, how brand-partner rewards are flowing). The two have different shapes, often pull from different sources, and have to land on the same dashboards for the team to make decisions. Doing all of that with a one-engineer engagement means picking tools that give a lot of leverage per line of SQL.

Approach

The brief was to ship a BI stack the team would actually use, not a perfect data platform. That framing drove every decision.

• ClickHouse for the warehouse. Right shape for the workload — analytical queries over event-shaped data, fast at the column-store work that dominates BI, cheap to operate at this scale.
• Metabase as the analytical surface. Non-engineers on the Mostt team can author and tweak their own questions; engineering doesn't become a bottleneck for every chart.
• SQL as the contract. Everyone — engineering, ops, product — reads the same SQL. No bespoke DSLs, no closed-source modeling layer between the data and the people asking questions.
• One engineer, end-to-end. Pipelines, schema design, dashboards, handover to the team. Splitting "data engineering" and "BI" at this scale would have been pure overhead.

Solution

The implementation lands data into ClickHouse, exposes it through SQL, and surfaces it through Metabase dashboards aligned to the team's product and finance questions. The schema is shaped around the way the Mostt team actually asks questions, not around the source-system structure — that's the leverage that lets a one-engineer engagement produce a useful BI surface.

Key features shipped

• ClickHouse warehouse with the source-of-truth analytical schema
• Pipelines into ClickHouse from the product systems
• Metabase dashboards covering product, growth, and financial metrics
• SQL conventions and documentation so the team can extend without re-engaging engineering

Outcome

The BI stack is live. The Mostt team operates against it directly. The handover model worked — engineering's involvement is no longer required for routine reporting changes.

• BI stack live in production
• Team self-serves new questions via Metabase + SQL without engineering involvement
• One-engineer delivery — the leverage came from tool choice, not headcount

Tech stack

Warehouse: ClickHouse BI / dashboards: Metabase Query language: SQL

What we learned

• ClickHouse + Metabase is a high-leverage default for product analytics. Fast at the workload that dominates BI, cheap to operate, no-friction self-serve on top.
• SQL as the contract beats every "no-code" data layer at this stage. The cost of teaching the team SQL is paid back the first time they ship a question without engineering.
• One engineer can deliver a real BI stack when the brief is "useful, not perfect" and the tool choices match.