Growth Engine: One Application, Two Surfaces

Growth Engine: One Application, Two Surfaces

A React front end, a Python backend, models running locally, and the same backend exposed as an MCP server. One implementation, two ways to consume it.

Project details

Named case study
Industry

Personal tooling, dogfooded daily

Timeline

2026, in continuous use

Tech Stack

React, TypeScript, Python, FastAPI, Ollama, MCP, SQLite

Built with
  • React
  • TypeScript
  • Python
  • FastAPI
  • Ollama (local inference)
  • Model Context Protocol

One backend, two ways in

Growth Engine is a complete application rather than a tool server: a React interface, a Python backend, a local database, model inference running locally, and an MCP server that exposes exactly the same backend to an agent.

That is the architectural point. A human opens the interface; an agent calls the MCP surface; both hit one implementation. There is no second copy of the business logic to keep in sync, and no drift between what the UI can do and what the agent can do.

101
green tests: 87 on the backend, 14 on the front end, executed rather than quoted from a README

The numbers

  • 49 API endpoints across 18 routers.
  • 13,400 lines of Python and TypeScript, excluding dependencies.
  • 101 tests, all green: 87 backend and 14 front end.
  • Local model inference by default, with an explicit cloud fallback enabled case by case. A cost and confidentiality choice, not an ideological one.

The real subject: responsible AI you can execute

LinkedIn's terms of use forbid automated publishing. That is a constraint the application has to respect, and there are two ways to respect it.

The common way is a line in a documentation file that nobody reads. The way I chose: the clause is quoted in the configuration file, next to the code it constrains, and publishing only goes out on an explicit human action.

A charter blocks nothing

Responsible AI usually arrives as a policy document, filed somewhere, referenced in an audit, and structurally incapable of preventing anything.

A constraint placed where someone could actually break it does prevent something. Quoting the terms of service in the config file, beside the function they restrict, means the next person to touch that code reads the reason before they change the behaviour. That is the difference between a principle and a control.

What it actually does

It tracks contributions, goals and activity: the operational side of a public technical practice, including the community and MVP contribution work that is otherwise scattered across a dozen platforms. It is a personal tool rather than a product, and the interesting part here is the architecture, not the feature list.

The repository is private, so there is no public link.