Analytics Site v2

A full-stack project that helped day traders analyze their trading performance
Projects
Full Stack
Code
Author

Aaron Carver

Published

June 2023

Analytics Site v2

Repo

Demo

  • No longer hosted online, but a couple video intros can be seen here:

Creating an account

Using the services

What was Analytics Site v2?

A site that helped day traders analyze their trading performance.

There were three services:

  • Journal Files - upload one’s brokerage files
  • Journal - see analysis of one’s trading data
  • Chat - chat with an LLM such as GPT-3.5 or GPT-4

About

Why I built the site:

  1. building things is fun
  2. to learn to build a product from scratch including selecting the stack (described below)
  3. inadvertently, as a “portfolio” project via which other people may see my work

I designed the architecture and wrote the code. A large amount of the time was just spent learning about various pieces of the stack. If I had to build it again from scratch, the process would be much faster.

What was the hard(est) part of building the site?

In general, the hardest part was not writing the code (e.g. React components) or using the pieces of the stack (e.g. querying Postgres).

The hardest part was making choices about the overall architecture, choosing the pieces of the stack, and getting everything to work together nicely.

This is a phenomena that Fred Brooks explains in The Mythical Man Month. He says that building a “programming systems product” is at least 9x harder than simply writing a program. I agree with that, especially the “at least” part.

The math behind this assertion is that it’s at least a 3x multiplier in effort to go from a “program” to a “programming system” which requires interfaces, system integration, and debugging all the things that go wrong when different piece of a stack are connected. There’s another at least 3x multiplier of effort required to go from a “program” to a “programming product” which requires generalization of functionality, testing, documentation, maintenance, authentication, etc.

Brooks gives us this brilliant, and haunting, diagram:

Programming systems product

Having built a programming systems product, I assert that I am thus a “9x engineer”, where x is a program.

Personally, I prefer this to the idea of being a “10x engineer”, where x is some imaginary person selected from one’s peers. The idea of being a 10x engineer is a fundamentally competitive idea.

The idea of being a 9x engineer is fundamentally about building things. The “x” is a program which can’t be used as part of a larger system or used by a large number of people. The 9x engineer creates not just the program, but the entire “programming systems product” which is the truly valuable thing in software development.

Competitive Focus and Build-Things-For-Users Focus might both be useful, but only one of them is fundamentally important.

Stack

Front-end Stack

Back-end Serverful Stack

Back-end Serverless Stack

CI/CD Stack

Auth Stack