Skip to main content

PortfolioEC - Delete before you ship!

 

How the Agile Complexification Inverter mindset shapes Portfolio Equity Curve App.


The Agile Complexification Inverter blog has a simple mantra: start by deleting. Remove the clutter, the “just in case” features, and the over‑engineered abstractions, and you’re often left with a system that’s easier to reason about and faster to ship.

From a developer’s point of view, PortfolioEC is an exercise in that same philosophy:

  • Delete the dashboard noise.

  • Delete the manual‑sync workflows.

  • Delete the un‑anchored analytics.

Then, and only then, build the tighter, more coherent system that’s actually worth maintaining.


Delete the “everything‑at‑once” dashboard

Most portfolio apps start with a “god‑dashboard”: pie charts, watchlists, news feeds, and AI‑score widgets competing for attention. As a product, that’s a complexity trap; as a developer, it’s a polyglot of state machines, background sync jobs, and overlapping UI layers.

PortfolioEC deletes that entire pattern and replaces it with:

  • single, stable entry point: the equity‑curve chart (1D, 1W, 1M, 3M, 1Y, 5Y, 10Y).

  • transaction‑overlay layer that visually anchors buy/sell marks to that curve, so most of the UI reduces to “curve + events + drill‑down”.

As a developer, that change looks like:

  • Fewer “top‑level” screens and views.

  • A smaller, more focused view‑model graph.

  • One canonical “what‑happened‑when” timeline instead of multiple inconsistent dashboards.

In short: delete the dashboard, keep the curve, and let almost everything else be a drill‑down or a detail panel.


Delete the manual‑sync and spreadsheet‑driven workflows

Traditional portfolio tracking often pushes the complexity onto the user:

  • Manually copy‑pasting trades into spreadsheets.

  • Hand‑adjusting lot‑basing after splits or corporate actions.

  • Cross‑referencing tax‑lot data between broker and app.

PortfolioEC deletes those manual steps by baking the complexity into the data layer instead of the UI:

  • FIFO cost‑basis and split‑adjustment logic lives in the model, with tests that cover re‑splits, reverse‑splits, and corporate shuffles.

  • Trade‑attribution overlays are computed from the transaction history, not entered by the user.

For your codebase, that means:

  • rich, well‑tested transaction model (buy/sell, splits, dividends, fees, transfers).

  • single source of truth for lots and cost‑basis, so features like “show which trades moved the curve” become pure queries rather than UI‑driven edits.

  • Less “spreadsheety” state in the UI, which in turn reduces the surface area for bugs and race conditions.

The complexity is still there, but it’s pushed into testable, composable logic, not user‑driven copy‑paste.


Delete the generic “investor‑type” abstraction

Many portfolio apps start with abstractions like “retail investor,” “day trader,” or “buy‑and‑hold,” and then try to build one UI that serves all of them. The result is a feature‑sprawl that makes the codebase hard to reason about and hard to refactor.

PortfolioEC instead deletes the “generic investor” persona and assumes:

  • An investor who cares about their own equity curve, not someone else’s benchmark.

  • A developer who wants to expose investor‑specific timelines and trade‑attribution, not generic “market news + a chart.”

For your backlog and architecture, this looks like:

  • Time‑based aggregates at the domain level: “curve by account,” “curve by asset class,” “curve by strategy.”

  • Trade‑attribution endpoints or view‑models that connect your transaction history to price data and events (earnings, dividends, splits).

  • UI that’s built around “what‑happened‑when” stories, not “what’s trending now in the market.”

This makes the architecture feel more like an event‑sourced system around portfolio historythan a generic “feed + chart” app.


Delete early optimization; optimize only after clarity

A core idea in the Agile Complexification Inverter is that you should never optimize early. First clarify the model, delete the noise, and then think about performance, caching, or AI‑assisted features.

Applied to PortfolioEC, that means a clear ordering for your backlog:

  1. Core model first

    • Transactions, lots, splits, dividends, fees, transfers.

    • Accurate FIFO cost‑basis and split‑adjusted curves.

  2. Sync and reliability

    • Account‑level history sync (broker + user‑entered).

    • Conflict resolution and data‑recovery paths.

  3. Visualization and analytics

    • Equity curve per account, asset class, and strategy.

    • Trade‑attribution overlays and drill‑downs.

  4. Then optimization and “smart” features

    • Prefetching and caching of historical curves.

    • Background pre‑calculation of trade‑impact metrics.

    • Eventually, AI‑assisted trade‑review or anomaly‑detection workflows.

If you invert that order — start with “smart recommendations” before you have a solid, testable model — you immediately end up with a brittle, entangled system where every feature is coupled to marketing hype and fragile data pipelines.



Delete features ruthlessly; keep the equity‑story

From a developer‑backlog perspective, the Agile Complexification Inverter question is:

“If we deleted this feature, would the core equity‑story still be clear and usable?”

Using that lens, PortfolioEC can obviously drop:

  • General‑market news feeds that don’t connect to your trades.

  • “Magic score” widgets that don’t reflect your actual cost‑basis or timing.

  • Over‑complicated watchlists that duplicate your existing portfolio data.

What you keep:

  • The equity curve + transaction overlays.

  • The event‑rich timeline (earnings, dividends, splits) tied to your trades.

  • The accurate, split‑adjusted cost‑basis that underpins every metric.

Everything else becomes a candidate for deletion — either now, or when it hasn’t demonstrably improved the investor’s understanding of their own equity story.


A complexity‑inverter developer’s backlog

If you were to summarize PortfolioEC’s developer backlog in Agile Complexification Inverter terms:

  • Delete:

    • Cross‑tool spreadsheet gymnastics.

    • Generic “investor persona” features.

    • Early‑stage AI‑hype features built on shaky data models.

  • Refactor:

    • The transaction and lot model into a well‑tested, split‑aware core.

    • The view‑model layer around “curve + events + drill‑downs.”

  • Add (only after clarity):

    • Fast, incremental sync and caching.

    • Trade‑attribution analytics and “what‑if” scenarios.

    • Optional, opt‑in AI‑assisted review of your own trade history.

The result is an app that doesn’t just ship faster — it’s simpler to reason about, easier to test, and more aligned with how real investors actually think about performance.


Comments