How to Build Software

Nov 06, 2025

I’m going to show everyone how easy it is to build software.

… and I’m going to do it by building a badass tool I’ve been wanting for years:

X-Ray vision for the stock market showing what the insiders are buying and selling.

The Vision: To build the leading tool that provides a consolidated, real-time, and AI-enhanced view of insider investment activities, empowering our users to make more informed decisions.

This isn’t just a CRM, it’s an “Insider Investment Intelligence Platform”.

When I get this built its going to be available at

Wealth Systems

, subscribe now:

Why Track Insiders?

I spent years in the belly of the beast, crunching numbers, valuing companies, and watching the market’s every tremor. I saw firsthand how information, especially privileged information, the kind available to insiders, could move markets.

Not the illegal kind, mind you, but the perfectly legitimate signals you can glean from public filings: who’s buying, who’s selling, and more importantly, when and why. The problem was, tracking this effectively was a nightmare. It was fragmented across SEC filings, company reports, and a dozen other disparate sources. We had CRMs, sure, but they were generic, built for sales pipelines, not for deciphering the subtle dance of insider investment.

That’s where the idea for our specialized CRM was born. I knew the pain point, intimately. Now, as someone who builds AI tools for my portfolio companies, I approach every project with the ruthless efficiency and strategic foresight I learned in banking, combined with the iterative flexibility of modern software development.

This isn’t just about writing code it’s about building a tool that solves a real problem for a specific user, in our case, sophisticated investors who need to track the often-opaque world of insider investments.

We’re going to use the Agile methodology because, frankly, the market moves too fast for anything else. We need to adapt, iterate, and deliver value constantly. That’s the future of software development in the age of AI.

How to Build Software

Chapter 1: Why Are We Doing This?

Every great software project starts with a clear, undeniable “why.”

For me, it was the frustration of missing signals in the market, the knowledge that valuable data was out there, but inaccessible in a consolidated, actionable format.

The Problem: Traditional CRMs are fantastic for managing sales leads and customer interactions. They fall flat when you need to track the complex, often non-linear, and highly nuanced investment activities of specific individuals (professional investors, corporate leaders, and politicians) across multiple public and private data sources. We’re talking about tracking their personal portfolios, their proxy statements, their 13D/G filings, their Form 4s, their Stock Act records, and connecting those to market movements and company performance.

This isn’t just a database or a toy project. It’s a predictive wealth intelligence engine waiting to be unleashed.

You start your adventure in paper, writing out the features you want to build.

Key Features (Initial Brainstorm):

Insider Profile Management: Detailed profiles for each insider (background, affiliations, historical roles).
Investment Tracking: Real-time logging of buys/sells, options exercises, gifts, etc., with links to source documents.
Company Linkage: Tie insiders to the companies they influence.
Portfolio View: Consolidated view of an insider’s known investment portfolio.
Alerts & Notifications: Customized alerts for significant insider activity.

This initial brainstorm isn’t a commitment. It’s a starting point for discussion. This is the stage where you’re still sketching on a napkin, but you’re doing it with purpose.

This is when I dig deep and think about how to USE the features I plan on developing to surface even more value. Typically, these take the form of additional features:

AI-Powered Anomaly Detection: Flagging unusual patterns or significant shifts.
Relationship Mapping: Visualizing connections between insiders, companies, and political entities.
Document Management: Storing and linking relevant public filings.

Now we have a great vision with granular features I can begin to work with.

Chapter 2: How We’ll Build It

Forget the multi-year project plans of old banking IT.

We have AI. We need to move fast. We’re going Agile.

Why? Because the market changes, technology evolves, and, frankly, our understanding of the best solution will deepen as we build. Agile lets us adapt and iterate.

Core Agile Concepts

This could take up a 7-part series by itself. Let’s give you a list of terms so you can start your learning process:

Sprints: Short, fixed-duration periods (typically 1-4 weeks) during which the team commits to completing a specific set of features. We’ll use 2-week sprints.
Product Backlog: A prioritized list of all desired features, bug fixes, and improvements for the product. Managed by the Product Owner.
Sprint Backlog: A subset of the Product Backlog that the team commits to completing during the current sprint.
User Stories: Short, simple descriptions of a feature from the perspective of the user. Example: “As a portfolio manager, I want to see a list of all current board members of ACME Corp, so I can track their public filings.”
Daily Stand-up (Scrum): A 15-minute daily meeting where each team member answers:
1. What did I do yesterday?
2. What will I do today?
3. Are there any impediments in my way?
Sprint Review: At the end of each sprint, the team demonstrates the completed features to stakeholders and gathers feedback.
Sprint Retrospective: The team reflects on the sprint – what went well, what could be improved, and how to make the next sprint better.

Dump these terms above in AI.

Write “I am just learning software engineering, can you unpack these for me and give me examples?”

Learn, learn, learn!

Tools of the Trade

For Agile project management, we’ll use tools like Jira, Trello, or Asana to manage our backlog, sprints, and tasks.

I’m a big fan of Linear as well.

For collaboration, Slack or Microsoft Teams.

For version control, Git (more on that later).

Chapter 3: How the System Works

Before we write a single line of code, we need a high-level architectural vision. This isn’t about minute details but about the major components and how they interact.

Think of it like deciding if you’re building a skyscraper or a ranch house… they require very different foundations.

Core Components

The data we are going to be targeting is messy, unstructured, and often in PDFs. We’ll need OCR (Optical Character Recognition) and NLP (Natural Language Processing) to extract meaningful information.

Data Ingestion & Processing Layer: This is the heart of our system, sucking in data from various sources.
- Sources: SEC EDGAR (Form 3, 4, 5, 13D/G), company press releases, news feeds, political donation databases, public director databases, market data providers.
- Tools: Python scripts, ETL pipelines, potentially cloud services like AWS Glue or Azure Data Factory.
Database Layer: Where all the structured data lives.
- Relational Database: Excellent for structured data, linking insiders to companies, tracking transactions.
- NoSQL Database: Potentially useful for unstructured documents, or for graph databases (Neo4j) to map complex relationships between insiders, companies, and political entities.
Backend Services Layer: The “brain” of the application. These services handle business logic, data retrieval, and interactions with the AI layer.
AI Layer: The neo-cortex or “intelligence” of our platform.
- Anomaly Detection: Flagging unusual trading patterns by insiders.
- Sentiment Analysis: Analyzing news and insider statements for sentiment.
- Entity Resolution: Identifying the same insider across different data sources, despite name variations.
- Relationship Inference: Discovering non-obvious connections.
UI/UX: The user-facing part.
- Technology: React, Angular, or Vue.js for a rich, interactive web experience.
- Key Design Principle: Intuitive dashboards, powerful search, clear visualizations of insider activity and relationships.
Authentication Securing access.
- OAuth2/JWT: Industry standards for secure access.
Cloud: Where everything runs.
- AWS, Azure, or Google Cloud Platform: Scalability, reliability, and access to advanced services. We’ll likely containerize our services using Docker and orchestrate them with Kubernetes.

High-Level Diagram

Imagine this:

[External Data Sources]
     | (SEC EDGAR, News, etc.)
     V
[Data Ingestion & Processing Layer]
     | (ETL, OCR, NLP)
     V
[Database Layer] <---> [AI Layer]
     |
     V
[Backend (APIs)]
     |
     V
[Frontend (Web)] <---> [User]

This diagram is intentionally high-level.

The exact technologies and detailed interactions will evolve as we build and learn.

Chapter 4: The Build

This is where the rubber meets the road.

We break down our vision into small, manageable chunks, prioritizing what delivers the most value first. Remember, the goal isn’t a perfect system from day one, but a functional system that can grow and adapt.

Sprint 1: Minimum Viable Product | Core Insider Profile & Basic Filings

Our first sprint will focus on getting the absolute minimum necessary features working end-to-end. The goal is to prove the core concept.

Sprint Goal: Establish the foundation for insider profiles and ingest/display basic Form 4 data.

One common way to think and act when you build software is to put yourself into the shoes of your user. Usually you write these out as stories, told from different perspectives.

As an administrator, I want to create an insider profile, so I can begin populating the system.
As a portfolio manager, I want to view an insider’s profile, including their name, title, and current company affiliations.
As an investor, I want to see a list of an insider’s Form 4 transactions (buy/sell), so I can track their recent activity.

There is a LOT to do when it comes to building software…

Sprint Planning: Break down user stories into tasks, assign tasks to developers.
Development:
- Set up initial Git repository structure.
- Configure PostgreSQL database schema for Insiders and Transactions tables.
- Develop Flask API endpoints for creating/retrieving insiders and transactions.
- Write Python parser for Form 4 XML.
- Build basic React components for Insider Profile and Transaction List.
Daily Stand-ups: Track progress, address blockers.
Testing: Manual testing of UI, unit tests for API endpoints and parser.
Sprint Review: Demonstrate working features (even if rudimentary).
Sprint Retrospective: Discuss what went well, what was challenging. (e.g., “Parsing XML was harder than expected; let’s allocate more time for data processing in the next sprint.”)

This incremental approach is crucial.

We’re not trying to build the whole skyscraper in one go.

We’re pouring a solid, usable foundation.

There’s a lot more to do. We need to set-up our backend and connect it to our front. We need to get our tables set-up to hold data and write SQL statements to push data around to the right places in the app. And so on. Sprint after sprint. Each sprint is a mini-project with a clear goal, resulting in a deployable, shippable increment of the product.

Chapter 5: How to Build It Well

This isn’t just about getting it done; it’s about getting it done right.

Poorly engineered software becomes a liability, a technical debt that costs more to maintain than to rebuild. My banking experience taught me the cost of hidden risks; here, technical debt is that hidden risk.

Version Control: Git | The Time Machine & Collaboration Maestro

Git is non-negotiable. It’s how teams coordinate, track changes, and revert mistakes.

Please learn what these terms mean before getting active building software:

Repository (Repo): The project folder managed by Git.
Commit: A snapshot of your changes at a specific point in time, with a message describing what you changed and why.
Branching: Creating separate lines of development.
- main (or master): The sacred, production-ready code.
- develop: Where integrated, tested features live before moving to main.
- Feature Branches (e.g., feature/add-insider-search): Where you do your individual work, isolated from others. This is your “topic branch.”
Pull Requests (PRs) / Merge Requests: When you finish a feature on your branch, you open a PR to merge it into develop. This triggers a code review.
Merge: Combining changes from one branch into another.

My Workflow:

git checkout develop: Start from the latest development code.
git pull origin develop: Ensure your local develop is up-to-date.
git checkout -b feature/my-new-feature: Create a new branch for your specific task.
Work, commit often with meaningful messages.
git push origin feature/my-new-feature: Push your branch to the remote repository.
Open a Pull Request: Request to merge feature/my-new-feature into develop.
Code Review: Get feedback from teammates.
Address Feedback, commit, push.
Merge: Once approved, your feature is integrated.

That is a simplified flow through the process of building using Git as your trusted source of truth.

Crucial Advice: Never, ever force push to shared branches (like develop or main). It rewrites history and can destroy collaborators’ work. Only force push on your own feature branch if you know exactly what you’re doing and no one else is using it.

I have the battle scars to prove the importance of this point!

Testing: Your Safety Net

Why Test?

Catch bugs early: Cheaper to fix.
Enable refactoring: You can confidently change code, knowing tests will catch regressions.
Documentation: Tests show how the code is intended to be used.

Tests are not optional. They are your automated quality assurance.

There are several flavors of test, each of them important.

Unit Tests: Test the smallest units of code (individual functions, methods) in isolation. For our Flask API, a unit test might check if create_insider_profile(data) correctly saves data to the database and returns a success message.
Integration Tests: Test how different components work together. For our IIIP, an integration test might check if the frontend can successfully call the backend API to retrieve Form 4 data, and if that data is correctly displayed.
End-to-End (E2E) Tests: Simulate a user’s full journey through the application (e.g., log in, search for an insider, view their transactions). Often done with tools like Cypress or Playwright for web applications.

Code Review: Peer Pressure for Excellence

I used to hate code review. Now I look forward to learning and getting new perspective (and badass tools).

Every line of code you write should be seen by another human before it hits develop, for these reasons:

Quality Improvement: Bugs are caught, edge cases considered.
Knowledge Sharing: Everyone learns from each other.
Consistency: Ensures adherence to coding standards.
Mentorship: Junior devs learn from experienced ones.
Bus Factor: Reduces reliance on a single person for a piece of code.

Clean Code: Clarity is King

Code is read far more often than it’s written.

Make it readable. Peer review will help you get to clean code faster.

But what IS clean code?

Meaningful Names: insider_id, transaction_type, fetch_sec_filings are better than id, type, getData.
Small Functions/Methods: Each function should do one thing and do it well (Single Responsibility Principle).
Comments: Explain why you made a complex decision, not what the code is doing (the code should be clear enough for the “what”).
Consistent Formatting: Use a linter (e.g., Black for Python, ESLint for JavaScript) and formatter to automatically enforce code style.

Chapter 6: Bringing It to Life

Building software in isolation is pointless. It needs to be used.

But to do that, it needs to be deployed.

Continuous Integration / Continuous Deployment

This is the automated pipeline that takes your code from your laptop to production.

Continuous Integration: Every time code is pushed to develop (or a feature branch), automated tests run. If tests pass, the code is integrated into the main branch. This catches integration issues early.
Continuous Deployment: Once code is integrated and tested, it’s automatically deployed to a staging environment, and potentially even to production.

For our IIIP, a CI/CD pipeline might look like this:

Developer pushes code to feature/my-new-feature.
CI system (GitHub Actions in my case) runs unit tests and linters on that branch.
If tests pass, a Pull Request is opened.
After code review and approval, the feature branch is merged into develop.
CI system runs all unit and integration tests on develop.
If tests pass, the code is automatically deployed to a staging environment for final review.
Once approved on staging, the code is deployed to production.

Let’s say it all works to plan.

Now what?

You need to host this someplace it can scale.

Cloud Infrastructure

Compute: AWS EC2 (virtual servers) or AWS Lambda (serverless functions for event-driven tasks like parsing a new SEC filing). We’d likely use Docker containers managed by AWS ECS or Kubernetes for our backend services.
Database: AWS RDS (managed PostgreSQL) and potentially AWS Neptune (managed graph database for Neo4j).
Storage: AWS S3 for storing raw SEC filings, processed data, and user uploaded documents.
Networking: AWS VPC (Virtual Private Cloud) to isolate our network, Load Balancers to distribute traffic.
Security: IAM (Identity and Access Management) for granular permissions.

But you can’t just set and forget. You need to keep your eyes on the prize when you develop an asset!

Monitoring & Alerting: The Eyes and Ears of Your System

Once your app is live, you need to know if it’s working as expected.

Logging: Every service should log important events (errors, warnings, user actions). Use a centralized logging system (e.g., AWS CloudWatch Logs, ELK Stack).
Metrics: Track performance indicators (CPU usage, memory, response times, database query performance, number of new filings processed, number of anomalies detected).
Alerting: Set up alerts for critical issues (e.g., “CPU usage above 80% for 5 minutes,” “API error rate above 5%,” “Data ingestion failed”).

An ounce of prevention is worth a pound of cure. Invest time giving yourself a clean view of system resources, user utilization and environment conditions.

Chapter 7: The Future

The beauty of Agile is that the journey never truly ends.

Software is a living product. Closer to an organism than a machine.

Feedback Loop

Continuously gather feedback from users. Never stop feeding that energy back into your product and company overall.

This is critical for shaping the product backlog and ensuring we’re always building the right features. Our sprint reviews are a formal part of this, but also informal chats, surveys, and support tickets.

Scaling

As our app gains users and processes more data, we’ll need to scale.

This means increasing our operational leverage + bulking up AND getting smarter!

Horizontal Scaling: Adding more servers (e.g., more EC2 instances, more containers) to handle increased load.
Database Optimization: Indexing, query tuning, potentially sharding or replication.
Microservices: Breaking down our monolithic backend into smaller, independent services to manage complexity and scale specific parts of the system more efficiently.

The Mindset Shift from Banking to Building

Leaving the trading floor for the terminal was a huge leap, but the core principles remain the same: identify opportunity, manage risk, execute with discipline, and adapt relentlessly.

In banking, you deal with abstract financial instruments.

In software engineering, you build tangible tools that solve real-world problems. The satisfaction of seeing a complex system work, knowing you’ve crafted an elegant solution to a difficult challenge, is immensely rewarding.

Building software requires patience, meticulous attention to detail, a willingness to learn, and an unwavering commitment to delivering value. But if you follow these principles, embrace the Agile mindset, and constantly seek to improve, you won’t just build software… you’ll build an intelligent edge that transforms how people operate.

And for a former banker, that’s the ultimate return on investment.

Head on over to Wealth Systems to get your hands on Insider Pulse when we release it later this month!

Friends: in addition to the 17% discount for becoming annual paid members, we are excited to announce an additional 10% discount when paying with Bitcoin. Reach out to me, these discounts stack on top of each other!

Thank you for helping us accelerate Life in the Singularity by sharing.

Share Life in the Singularity

I started Life in the Singularity in May 2023 to track all the accelerating changes in AI/ML, robotics, quantum computing and the rest of the technologies accelerating humanity forward into the future. I’m an investor in over a dozen technology companies and I needed a canvas to unfold and examine all the acceleration and breakthroughs across science and technology.

Our brilliant audience includes engineers and executives, incredible technologists, tons of investors, Fortune-500 board members and thousands of people who want to use technology to maximize the utility in their lives.

To help us continue our growth, would you please engage with this post and share us far and wide?! 🙏

Life in the Singularity

How to Build Software

Why Track Insiders?

How to Build Software

Chapter 1: Why Are We Doing This?

Chapter 2: How We’ll Build It

Core Agile Concepts

Tools of the Trade

Chapter 3: How the System Works

Core Components

High-Level Diagram

Chapter 4: The Build

Sprint 1: Minimum Viable Product | Core Insider Profile & Basic Filings

Chapter 5: How to Build It Well

Version Control: Git | The Time Machine & Collaboration Maestro

Testing: Your Safety Net

Code Review: Peer Pressure for Excellence

Clean Code: Clarity is King

Chapter 6: Bringing It to Life

Continuous Integration / Continuous Deployment

Cloud Infrastructure

Monitoring & Alerting: The Eyes and Ears of Your System

Chapter 7: The Future

Feedback Loop

Scaling

The Mindset Shift from Banking to Building

Discussion about this post