Abhinav Kumar Dwivedi

Product leader tailored for the new internet. Building digital products that matter.

Sitemap

  • Index
  • Projects
  • Blog
  • About

Socials

  • LinkedIn
  • x
  • GitHub
  • Email
© 2026 All Rights Reserved
New Delhi,India / Remote

Project Delta

Simple. Confident. Lets the content do the work.

0%

Project Delta

Simple. Confident. Lets the content do the work.

Indie Developer2026
Project Delta
01

The Challenge

Portfolio tools optimize for layout, not thinking.

What that causes:

  • No enforced structure

  • Decisions, trade-offs, and impact have no fixed place

  • Writers must re-decide how to think on every case study

The failure mode:

  • Case studies become long but directionless

  • Context grows, judgment disappears

  • Nothing is technically broken, but clarity degrades

Who this affects:

  • Anyone trying to communicate judgment through case studies

The cost:

  • Good work fails to signal decision quality

This is the gap Project Delta intentionally exploits.

02

The Goal

  • Make it easier to structure thinking, not just write case studies

  • Surface decisions, trade-offs, and impact explicitly instead of burying them in prose

  • Reduce decision fatigue when starting and revisiting case studies

  • Enforce consistency across projects so each case study follows the same mental model

  • Validate whether rigid structure leads to clearer reasoning in real use

I intentionally did not try to build a flexible or general-purpose CMS. Supporting heavy customization, multiple writing styles, or multiple users would have diluted the core goal.

To achieve this, I was willing to sacrifice flexibility and speed of writing in exchange for clearer, more legible judgment.

A secondary goal was to make decision quality visible without requiring long explanations or storytelling.

Overview

Project Delta is a private tool I built after repeatedly breaking my own portfolio.

The issue wasn’t effort, it was re-deciding where decisions, impact, and learnings belonged every time I added a new case study. Most tools optimize for layout, which makes structure optional and judgment implicit.

Project Delta treats case studies as structured reasoning, not free-form content.
Decisions, trade-offs, impact, and learnings are fixed elements, designed to reduce cognitive load and make judgment legible.

I kept it single-user and intentionally constrained, cutting analytics, deep version history, theming, and multi-user support to avoid overbuilding before understanding how people actually reason through their work.

Project Delta is rigid by design.
That rigidity prevents ambiguity and that’s the point.

It’s an experiment in encoding abstract thinking into rigid structures without killing usability.

In-Depth Analysis

Context & Constraints

The conditions and limitations that shaped Project Delta’s scope, trade-offs, and design decisions

01 — The Context

Working Solo, Under Real Constraints

"Rigid constraints weren’t a limitation, they were the mechanism that exposed unclear thinking."

I built Project Delta as a solo, indie project, alongside my studies, with limited time and no external users. From the start, I was the only person using the product, and I treated that as a design constraint, not a shortcut.

Because of this, I optimized for clarity and speed over scalability. The goal wasn’t to build a flexible platform — it was to validate whether structured case studies actually improved how I reasoned about my work.

I deliberately avoided multi-user authentication and account management. Supporting multiple users would have forced premature decisions around onboarding, permissions, and data isolation before the core structure was proven.

The most uncomfortable constraint was rigidity. Locking content into fixed structures meant I couldn’t rely on free-form writing when something felt unclear. That friction was intentional — it exposed weak thinking instead of hiding it behind prose.

Time was the final constraint. I spent roughly two months building Project Delta, which forced strict scope discipline. Draft vs publish was enough. Anything else had to justify its complexity.

One constraint I underestimated was version history. I assumed it would be straightforward, but it became one of the most complex and fragile parts of the system. Even now, it’s imperfect — reinforcing my bias toward minimizing state and avoiding features that multiply complexity too early.

Key Insights

Built as a solo project, alongside studies
Single-user by design to avoid premature complexity
Deliberately rigid structure to surface unclear thinking
Analytics intentionally excluded pending real user insight
Version history underestimated and remains fragile

Process Breakdown

Step 01

Define the Structure

Identified what a “good” case study actually consists of by analyzing portfolios from designers, studios, and product articles. Extracted common sections and signals that consistently communicated decision quality.

1
Step 02

Formalize the Schema

Converted those patterns into a fixed module list and content schema. Decided what was mandatory vs optional to prevent ambiguity while writing.

2
Step 03

Hardcode Before Abstracting

Built a hardcoded version of the portfolio to validate the structure against real content before introducing configuration or flexibility.

3
Step 04

Build the Admin Flow

Designed the admin interface around the schema, focusing on reducing decision fatigue while editing rather than maximizing flexibility.

4
Step 05

Iterate on Friction Points

Repeatedly refined module boundaries and the editing flow. Adjusted rigidity when it slowed writing and tightened it when clarity degraded.

5
Step 06

Use It End-to-End

Published the project and used it for my own work. The moment writing felt calmer and more deliberate confirmed the approach was working.

6

Decisions That Shaped the Product

Decision 01

Enforce a Modular, Schema-Driven Editor

Most portfolio tools rely on rich text and flexible layouts, which makes structure optional and inconsistent across projects. I needed a system that enforced how case studies are constructed instead of leaving it to discipline.

Selected Path

The Decision

I built a modular, schema-driven editor where case studies are composed of predefined sections. Decisions, trade-offs, and impact have fixed places, enforced by the system rather than writing conventions.

Outcome & Impact
Consistent structure across all case studies
Reduced flexibility when something doesn’t fit cleanly
Writing feels slower at first
Paths Not Taken
Traditional Rich-Text CMS
Rejected

Free-form editor with headings and sections

Why:Allowed ambiguity and inconsistent structure; judgment remained implicit

Template-Based Pages
Rejected

Reusable layouts with editable content

Decision 02

Remove Free-Form Writing

Free-form writing made it easy to over-explain context and avoid committing to clear decisions. It optimized for comfort, not clarity.

Selected Path

The Decision

I intentionally removed free-form writing inside core modules. Content had to fit the structure, forcing me to clarify ideas instead of hiding them in prose.

Outcome & Impact
Clearer, more deliberate case studies
Higher friction while writing
Less expressive storytelling
Paths Not Taken
Allow Rich Text Inside Modules
Rejected

Let users write freely within structured sections

Why:Reintroduced ambiguity and diluted the benefit of enforced structure

Hybrid Approach
Rejected

Mix rigid sections with open text areas

Why:Created inconsistency and decision fatigue while editing

Decision 03

Stay Single-User and Limit Theming

At this stage, Project Delta was a private tool used only by me. Supporting multiple users or extensive theming would have added complexity without validating the core idea.

Selected Path

The Decision

I chose to keep the product single-user and restrict theming to a fixed design system. This allowed me to focus entirely on structure and reasoning quality.

Outcome & Impact
Faster iteration and clearer product focus
Limited scalability
Not ready for public users
Paths Not Taken
Multi-User Authentication Early
Rejected

Support multiple accounts and shared access

Why:Premature complexity before validating core value

Customizable Themes
Rejected

User-controlled visual customization

Why:Shifted focus from thinking to aesthetics

The Solution

An opinionated system designed to make product thinking explicit and repeatable.

01
Core Feature

Schema-Driven Case Studies

Structure is enforced by the system, not the writer.

The Challenge

"Free-form tools make structure optional, leading to inconsistent and directionless case studies where decisions and impact are easy to miss."

Instead of treating case studies as pages, Project Delta treats them as structured data. Each case study is composed of predefined modules with clear responsibilities. This removes ambiguity about where information belongs and ensures every project follows the same mental model.

Structure is decided upfront, allowing writing to focus on decision quality rather than formatting or organization.

Capabilities

  • Predefined, opinionated modules
  • Mandatory vs optional sections
  • Consistent structure across all projects
Reduced time spent restructuring content and revisiting organization decisions across projects.
02
Core Feature

Decision-Focused Editing Flow

Clarity over comfort while writing.

The Challenge

"Free-form writing encourages over-explaining context and avoiding clear commitments, resulting in vague narratives."

The editor deliberately limits free-form writing within core sections. Content must fit the structure, forcing ideas to be expressed clearly instead of hidden in prose.

This introduces short-term friction, but consistently leads to more deliberate and focused case studies.

Capabilities

  • Limited rich-text flexibility
  • Structured inputs over open text
  • Reduced decision fatigue while editing
Clearer articulation of decisions and trade-offs with less redundant context.
03
Core Feature

Admin-First, Single-User Workflow

Focus on thinking, not configuration.

The Challenge

"Multi-user systems and heavy customization add complexity before the core value is proven."

Project Delta is intentionally single-user with a fixed design system. This removes the need to think about permissions, onboarding, or theming and keeps attention on content quality and reasoning.

By reducing surface area, the system stays focused on its core purpose: making judgment legible.

Capabilities

  • Single-user architecture
  • Fixed design system
  • Draft vs publish workflow
Faster iteration and clearer product focus during active use.

Outcome & Impact

The observable impact of enforcing structure on how case studies were written and evaluated.

Project Goal

Demonstrate that enforcing structure improves clarity, consistency, and decision quality when documenting product work.

Business Impact
💬 Qualitative

Clearer Case Studies

Case studies became shorter, more focused, and easier to scan for decisions, trade-offs, and outcomes.

Observed through repeated personal use while writing and revisiting multiple projects over time.

Goal Alignment
Make product judgment explicit and easy to evaluate.
User Impact
💬 Qualitative

Reduced Decision Fatigue While Writing

Writing shifted from organizing content to articulating decisions, with less time spent rethinking structure.

Compared writing flow before and after switching from free-form tools to Project Delta.

Goal Alignment
Reduce cognitive load when creating and maintaining case studies.
Technical Impact
💬 Qualitative

Improved Reusability Over Time

Older case studies could be revisited, updated, and compared without rewriting or restructuring content.

Tested by revisiting previously published projects and making incremental updates.

Goal Alignment
Enforce long-term consistency across projects.

What’s Next

An intentional roadmap focused on validating structure before scaling.

Product Vision

Evolve Project Delta from a private system into a public, opinionated platform for structured case studies, without sacrificing clarity or decision quality.

Prioritization Approach

Features are prioritized based on whether they preserve the core constraint, enforced structure - while expanding usefulness beyond a single user. Anything that adds flexibility too early is intentionally delayed.

Now
Next 1-2 months

Multi-User Support

medium
Now
Planned
Platform

Introduce account-based access so multiple users can create and manage their own structured case studies, while preserving the same schema-driven constraints.

💡 User Value

Allows others to benefit from structured case studies without needing to build their own system.

📊 Business Impact

Enables broader adoption and validates whether the core structure holds up beyond a single user.

⚠️ Challenges

Risk of introducing premature complexity around permissions, onboarding, and data isolation.

✓ Success Metrics
  • Successful onboarding of first external users
  • Case studies created without schema breakage
Next
3-6 months

Constrained Theming

medium
Next
Planned
UX

Add limited theming options (e.g. typography scale, spacing presets) without allowing full visual customization that could undermine hierarchy and readability.

💡 User Value

Allows light personalization while maintaining a consistent, professional presentation.

📊 Business Impact

Improves appeal to a wider audience without increasing support or design complexity.

⚠️ Challenges

Over-customization could reintroduce layout-first thinking.

✓ Success Metrics
  • No increase in structural inconsistency across projects

Stabilized Version History

medium
Next
Planned
Infrastructure

Refine and harden version history to make drafts, changes, and rollbacks more reliable without significantly increasing system complexity.

💡 User Value

Improves confidence when editing and revisiting older case studies.

📊 Business Impact

Reduces friction for long-term use and maintenance of case studies.

⚠️ Challenges

State complexity and edge cases could slow development.

✓ Success Metrics
  • Reduced errors during save and publish flows
  • Reliable rollback to previous versions
Retrospective

Learnings

A look back at what I learned.

01

Key Takeaway

Core lesson

Rigid structure exposed unclear thinking faster than any feedback loop. Whenever something didn’t fit the schema, it usually meant the decision itself wasn’t fully formed.

02

Paradigm Shift

New perspective

I initially believed flexibility helped express ideas better. This project changed that belief—removing options actually improved clarity and focus while writing.

03

The Surprise

Unexpected discovery

The biggest impact wasn’t external adoption or metrics. It was how much calmer and more deliberate writing felt once structure was enforced.

04

The Mistake

What went wrong

I underestimated the complexity of version history. Even a “simple” draft system introduced more state and edge cases than expected, creating fragility early on.

05

Growth Area

Future opportunity

If I were to do this again, I would delay scalability even more aggressively and validate the core structure with additional real users before adding complexity.