# Projects

> Technical projects with architecture decision records (ADRs), plus the building philosophy that guides them. The building philosophy is included in full at the end of this page.

- HTML version: https://robbiepalmer.me/projects

## Projects

### [Recipe Site](https://robbiepalmer.me/projects/recipe-site.md)

A digital recipe book that replaces handwritten collections with powerful search, filtering, and kitchen-friendly features (status: live). 42 architecture decision records (ADRs) are listed on the project page.

### [Personal Finance App](https://robbiepalmer.me/projects/personal-finance-app.md)

Data-entry-first financial planning — the missing tool between budgeting apps and advisor software (status: idea).

### [Personal Site](https://robbiepalmer.me/projects/personal-site.md)

My personal portfolio (status: live). 45 architecture decision records (ADRs) are listed on the project page.

### [AI Shopping Assistant](https://robbiepalmer.me/projects/chatbot.md)

A conversational agent using RAG, hybrid search, and SSE streaming (status: completed).

### [Multi-Modal Product Search](https://robbiepalmer.me/projects/multi-modal-product-search.md)

Enabling 'snap-to-search' for finding best deals using a visual vector database (status: completed).

### [Commercial Knowledge Graph](https://robbiepalmer.me/projects/commercial-knowledge-graph.md)

Building a commercial knowledge graph from unstructured email history and receipt photos using computer vision and LLMs (status: completed).

### [Python UDFs for Confluent Platform](https://robbiepalmer.me/projects/confluent-python-udfs.md)

Bringing the Python Machine Learning ecosystem to Kafka via UDFs for ksqlDB and Kafka Connect (status: completed).

### [Customer Health Forecasting](https://robbiepalmer.me/projects/customer-health-forecasting.md)

Investigation into predictive analytics for Net Revenue Retention (NRR) and customer churn (status: completed).

### [Automated PII Detection](https://robbiepalmer.me/projects/pii-detection.md)

Real-time PII detection and redaction for cyber defense using NLP and Kafka (status: completed).

### [Pathology Viewer](https://robbiepalmer.me/projects/pathology-viewer.md)

A web app for interacting with digital pathology slides (status: completed).

### [Bioinformatics Research Platform](https://robbiepalmer.me/projects/bioinformatics-platform.md)

A no-code, polyglot environment for bioinformatics EDA and ML inference (status: completed).

### [Automated Tumor Macrodissection](https://robbiepalmer.me/projects/automated-macrodissection.md)

AI-driven tissue selection for precise downstream genetic analysis (status: completed).

### [Genomic Prediction from Histology](https://robbiepalmer.me/projects/genomic-prediction.md)

Predicting genomic status (MSI/MSS) from standard H&E pathology slides using Deep Learning (status: completed).

### [AI-Assisted Macrodissection Runtime](https://robbiepalmer.me/projects/ai-assisted-macrodissection.md)

A platform for scaling AI models to accelerate manual tissue macrodissection (status: completed).

# Building Philosophy

## Short Feedback Loops

No matter how many times this is proven, it is surprisingly unintuitive and easily forgotten.
Spending more time planning and debating makes you more likely to fail.
Internal feedback is navel gazing. External engagement is reality.

Real users are the best test you'll ever have. Ship first.
Early adopters are forgiving if they see you're responsive and have momentum.

People add process constantly - release managers, approval gates, "safety" mechanisms.
Decades of evidence says this kills velocity, increases the rate of incidents and leads to building the wrong thing.

Shorten the path from idea to production.

## Build Flywheels

Build self-reinforcing systems - make small investments that compound.
Linear effort, exponential payoff.
Don't make flashy, one-off wins.
If the work doesn't compound, don't do it.
Flywheels should spin fast and stay light.

## Leverage Tech Debt

The optimal amount of tech debt is not zero. It is a tool, not a sin.
Strategic debt doesn't just make you faster - it makes things possible at all.

Friction is a resource allocation problem.
Where friction sits should reflect current priorities.
Not hiring? Optimizing onboarding is a waste.
Pre-product-market fit? Incomplete test coverage is fine - ship and learn.

## Avoid Negative Compounding

Debt with low interest, invested well, is powerful leverage.
Debt with high interest, invested badly, will make you bankrupt.

Some tech leaders miss the impact of having tech debt in the wrong place.
When shipping is hard, people stop trying.
Slow deployments don't just delay new features going to customers.
They cause lost productivity through context-switching.
Incidents take longer because no one remembers what changed, so deploys get more cautious and less frequent.
People fill time with what's available — bikeshedding, process tweaks, planning from the ivory tower.
The impact compounds until value delivery grinds to a halt.

## Stack Rank, Don't Sprint

Planning should clarify priority, not predict the future.

Don't tie yourself to arbitrary timelines.
Always be ready to address real customer feedback, or respond to new innovation and discovery.

Project management is the act of [balancing resources, time and scope](https://asana.com/resources/project-management-triangle).
Scope should *always* be relentlessly decreased to get to MVP and discover PMF.
Balance your resources per project to get the velocity you want.

What works: a stack-ranked list at multiple levels of abstraction - tasks, epics, initiatives.
Always know what's most important right now. Reprioritize constantly as you learn.

## The Goldilocks Zone

Pick technologies old enough to be reliable and well-documented, but not so old they're unsupported or talent-scarce.
Early adopters pay the cost of missing documentation, unpatched bugs, and shifting APIs.
Late adopters pay the cost of shrinking community and looming deprecation.
The window in between is where you want to be.

**Selection criteria:**

* **High floor, high ceiling** — Pick tools that make it hard to write bad code, but that scale to complex needs
* **Shallow ramp** — Easy onboarding for yourself and collaborators, enabling balanced focus on customer problems, not fighting technology
* **Rising tides** — Build on platforms that are themselves growing and improving. Their momentum becomes yours

When adopting new tech, do it deliberately and one at a time.
People often don't respect learning rate - the capacity of a team to absorb new domain knowledge,
tooling, and process at once.
Don't compound risk by going bleeding-edge on multiple fronts simultaneously.

## Split By Constraint, Not Dogma

Don't split services because "microservices are best practice." Split when you hit a real constraint -

* GPU workloads need different infrastructure than CPU
* Mobile phones vs servers need different artifacts
* Different scaling characteristics need different resources

Start as a monolith. Let actual constraints drive the architecture, not org charts or resume-driven development.

## Less Is More

Every additional line of code you write is additional maintenance burden.
Build only what makes you unique. Rent the rest.
If it's not your core business, buying is almost always cheaper than building and maintaining.
Consolidate where possible.
Prefer tools that solve multiple problems over specialized single-purpose services.

## LLM-Optimized

Every architectural decision needs to account for AI collaboration.
AI feeds on context. If it isn't in the repo, it doesn't exist.
Everything as code - content, infrastructure, database.

This has the extra benefit of encouraging general good practice for collaboration with team-mates;
having clear naming conventions and predictable patterns. But now with stronger justification when trade-offs arise.

Boring tech is AI-readable tech. The model has seen `React` a billion times; it's hallucinating your bespoke framework.

## Documentation Rots

Writing documentation has immense value at the time.
It forces clarity of thinking, captures nuance that gets lost verbally, and synchronizes teams.

But that value has a short shelf life.
Documentation is not connected to self-reinforcing feedback loops the way code is.
Code gets run by users, consumed by tests, validated constantly.
It gets continually rewritten and replaced as understanding of the product evolves.
But documentation grows and gets abandoned. Minimize it where possible.
Trust the code, not the comment.
Write for the moment. Don't expect it to last.

## Build in Public

Building in private has costs people rarely account for.
Security, access control, tooling to manage it all - energy not going into the product.

Public repositories are also directly cheaper.
Many products/services provide free tiers for open-source code e.g. GitHub Actions
and CodeRabbit.

Showing mistakes matters as much as showing wins.
Fast feedback and incremental shipping mean things will be imperfect in public.
That's fine - visibility forces focus on what is truly important.

## Generalists Over Specialists

Specialists become bottlenecks. They create queues, handoffs, and artificial boundaries.

T-shaped engineers - broad knowledge, deep in one or two areas - move faster and see the whole picture.
They can unblock themselves. They don't wait for "the frontend person", "the tester", "the data scientist".

## Respect Goodhart's and Conway's Laws

Goodhart's Law: when a measure becomes a target, it ceases to be a good measure.
Do not hold people to account for proxies.

Conway's Law: systems mirror the communication structures of the organizations that build them.
Structure your teams to get the architecture you want.

---

Markdown index of this site: https://robbiepalmer.me/llms.txt