Adam Wiggins co-founded Heroku, authored The Twelve-Factor App, and later worked on Ink & Switch, Muse and local-first software. These lessons trace his thinking about developer tools, software design and collaboration. — Adam Wiggins.

Visual summary of operating lessons from Adam Wiggins.

Part 1: The Philosophy of Computing

  1. Making Computers Better: Wiggins frames his work as trying to make computers more useful to people, not just advancing technology for its own sake. — InfoWorld Interview.
  2. The Long Trajectory: A small change in the direction of computing today can have a much larger effect over decades. — InfoWorld Interview.
  3. Technology as a Means: Programming and technology matter because of the human problems a product can solve. — InfoWorld Interview.
  4. Art and Software: Wiggins describes building Heroku and later projects as both a career and a form of creative expression. — MAPS Bulletin Interview.
  5. Human Agency in Technology: Technical futures are shaped by human choices; builders can choose to make computing more beneficial. — InfoWorld Interview.
  6. End-User Programming: Wiggins wants more people to be able to create software, rather than leaving programming to a small professional class. — My Heroku Values.
  7. Product Value and Complexity: A product becomes more valuable when it solves more problems without making users hold more complexity in their heads. — My Heroku Values.
  8. Vision Grounded in Reality: Wiggins invokes Bill Buxton’s “head in the clouds, feet in the mud” to pair ambitious ideas with practical building. — InfoWorld Interview.
  9. Make Change Testable: Treat products, features and team processes as experiments that can change or end when evidence warrants it. — My Heroku Values.
  10. Keep Experimentation Cheap: Make concrete prototypes early; the less costly an idea is to try, the more readily a team can learn from it. — My Heroku Values.
  11. LLMs and Craft: LLMs can lower the cost of making software, but Wiggins worries that speed can flatten deliberate craft and design. — Politics and Emotion at Local-First Conf.
  12. Human Software: Wiggins argues for space to make software that feels unusual, human and enjoyable rather than uniformly optimized. — Politics and Emotion at Local-First Conf.
  13. Ship to Real Users: A prototype becomes consequential only when a real person uses it to solve a problem. — My Heroku Values.

Part 2: The Twelve-Factor App & Engineering

  1. The Twelve-Factor Method: Wiggins wrote The Twelve-Factor App as a method for building portable, resilient software-as-a-service applications. — The Twelve-Factor App.
  2. Disposability: Build processes that start quickly and shut down gracefully so deployment, scaling and recovery are easier. — The Twelve-Factor App: Disposability.
  3. Dev/Prod Parity: Keep development, staging and production close in time, people and tools to reduce deployment friction. — The Twelve-Factor App: Dev/Prod Parity.
  4. Config in the Environment: Keep values that vary by deploy separate from code and store them in environment variables. — The Twelve-Factor App: Config.
  5. Port Binding: Have the application expose its own service through a port rather than rely on a web server injected by its runtime. — The Twelve-Factor App: Port Binding.
  6. Backing Services: Treat databases, queues and similar backing services as attached resources with explicit connections. — The Twelve-Factor App: Backing Services.
  7. Concurrency: Scale an application by running more instances of its defined process types. — The Twelve-Factor App: Concurrency.
  8. Logs as Event Streams: Let application processes write logs to standard output and leave routing and storage to the execution environment. — The Twelve-Factor App: Logs.
  9. Why the Manifesto Mattered: The Twelve-Factor App helped explain the cloud-native deployment model Heroku was building for developers. — Changelog Heroku Interview.
  10. Fast Feedback for Developers: Heroku sought to shorten the path from code to a running application, making experimentation and deployment easier. — Making Computers Better: Create.

Part 3: The Origins of Heroku & Startups

  1. Heroku’s Starting Problem: Repeatedly deploying client projects exposed the friction of provisioning servers, prompting Wiggins and his collaborators to build a developer platform. — Changelog Heroku Interview.
  2. From Idea to Reality: Wiggins enjoys turning a small idea into a product that exists and can be used. — InfoWorld Interview.
  3. Solve a Problem First: Wiggins advises starting a company to solve a real problem, not making company formation the goal in itself. — InfoWorld Interview.
  4. A Personal Source of Perspective: Wiggins says psychedelic experiences helped him think more expansively while creating Heroku; this is his personal account, not a general efficacy claim. — MAPS Bulletin Interview.
  5. Responsibility for Users: Wiggins described Heroku as work he cared about deeply because many applications depended on it. — Leaving Heroku.
  6. Remove Server Work from the Developer Path: Heroku’s goal was to let developers deploy applications without having to manage server setup as the core task. — Changelog Heroku Interview.
  7. Let Ideas Develop: During ideation, let rough material develop before judging it as a finished plan. — Metamuse: Remote Work.
  8. Aesthetic Ambition: Wiggins wanted developer tools to solve concrete problems while still being stylish, expressive and enjoyable. — My Heroku Values.
  9. Focus on the Application: Heroku shifted developer attention from managing infrastructure toward building and shipping applications. — InfoQ Podcast.

Part 4: Local-First Software

  1. The Local-First Aim: Local-first software seeks the collaborative benefits of cloud applications while giving people more control over their work and data. — Local-First Software.
  2. Work Offline: A local-first application should remain useful without a network connection and synchronize when a connection returns. — Local-First Software.
  3. Data Longevity: Local-first design aims to keep work accessible even if a cloud service disappears. — Local-First Software.
  4. Combine Cloud and Desktop Strengths: The design target combines collaboration across devices with local responsiveness, ownership and offline access. — Local-First Software.
  5. Merge Concurrent Edits: CRDTs are one technique for merging edits made independently on different devices; a local-first product may still use servers for relay and availability. — Local-First Software.
  6. Own the Data: Keeping usable local copies of work gives users more control than relying on a provider as the sole holder of their data. — Local-First Software.
  7. Respond Locally: When an application can read and write a local copy, ordinary interactions need not wait for a round trip to a server. — Local-First Software.
  8. User Agency: Local-first systems are designed to give people practical control over their files, software and collaboration. — Local-First Software.
  9. Collaborate Without Cloud Lock-In: Real-time collaboration need not require making a vendor’s cloud the only usable home for the work. — Local-First Software.
  10. Software Sovereignty: Wiggins connects open protocols and local-first infrastructure to greater national control over critical software. — Politics and Emotion at Local-First Conf.
  11. Agents and Shared State: Wiggins sees local-first sync as a way for agents and human collaborators to work against shared state. — Why Sync?.

Part 5: Tools for Thought & Cognitive Augmentation

  1. Tools Shape Thought: The form of a thinking tool influences what ideas people can explore and what they produce. — Muse Retrospective.
  2. A Spatial Canvas: Muse explored a freeform canvas for collecting and developing ideas without forcing them into a linear document. — Muse Retrospective.
  3. Room for Messy Ideation: Early creative work can be scattered; a thinking tool should let people arrange and revisit rough material. — Muse Retrospective.
  4. Pause Before Converging: Wiggins describes stepping away from an idea and returning with a clearer view rather than forcing an immediate conclusion. — Metamuse: Remote Work.
  5. Fluid Thinking Tools: Muse’s canvas experiments sought to make moving among notes, sketches and source material feel fluid. — Muse Retrospective.
  6. Tactile Input: Muse’s origins joined tablet, touch and stylus input with a canvas for the ideation stage of work. — Muse Retrospective.
  7. Malleable Tools: Wiggins’s personal-feed experiment shows the appeal of software whose rules users can adapt for themselves. — A Bluesky Feed for One.
  8. Knowledge-Work Software Is Still Developing: Ink & Switch investigated how computing environments might better support writers, researchers, designers and other knowledge workers. — Muse Retrospective.
  9. Interaction Details Matter: Muse’s team had to iterate on even foundational canvas interactions, such as zooming, before users could rely on them. — Muse Retrospective.
  10. Keep Work Portable: Local-first design favors data that remains accessible and usable outside a single provider’s service. — Local-First Software.
  11. Own the Feed Algorithm: In building a personal Bluesky feed, Wiggins found that likes can be social gestures rather than reliable signals of what he wants to read. — A Bluesky Feed for One.
  12. Personal Ranking: Wiggins proposes ranking incoming messages against personal priorities and improving that ranking through lightweight feedback. — Personal Information Firehose.
  13. Manage the Receiving Side: Publishing and sending information became easy; tools for handling what arrives have not kept pace. — Personal Information Firehose.
  14. Version Control Beyond Code: Wiggins imagines bringing version-control-style history and collaboration to documents and other everyday work. — InfoQ Podcast.

Part 6: Design & Software Architecture

  1. Simple Surface, Broad Utility: Wiggins contrasts an adaptable touchscreen with a button-heavy remote: hide complexity so a simple interface can address many tasks. — My Heroku Values.
  2. Explore Options Before Choosing: Design requires considering alternatives and concrete prototypes before settling on an approach. — My Heroku Values.
  3. Find the Right Problem and Design: Use sketches and prototypes to test a design direction before polishing implementation details. — My Heroku Values.
  4. Make Problems Concrete: Sketch a prototype or workflow instead of debating only abstract descriptions of a problem. — My Heroku Values.
  5. LLMs as a New Medium: Wiggins sees language models as a new medium whose design possibilities are still being discovered. — Living Documents as a UX Pattern in AI.
  6. Learn from Earlier Computing Shifts: Wiggins compares LLMs with earlier GUI, web and mobile shifts that opened new design practices, while stressing that builders must learn the new medium’s constraints. — Living Documents as a UX Pattern in AI.
  7. Engineering and Product Together: Bring technical possibility and real user problems into the same product conversation. — My Heroku Values.
  8. Divide Hard Problems: Wiggins recommends cutting a difficult problem into smaller pieces and keeping the interface between pieces narrow and clear. — My Heroku Values.
  9. Architecture Affects Experience: Choices about where data lives and how it synchronizes shape responsiveness, offline use and collaboration. — Why Sync?.
  10. Simplify with Sync: A sync-based local-first stack can remove much of the application-specific caching, optimistic UI and CRUD plumbing. — Why Sync?.
  11. Unbundle the Feed: Separate publishing, feed algorithms and reading clients so users can choose or build their own curation. — A Bluesky Feed for One.
  12. Distribute Agent Work: Wiggins discusses agent workflows that can span local systems and remote services rather than depend on one centralized application. — InfoQ Podcast.

Part 7: Independent Research Labs

  1. Learn from Industrial Research: Ink & Switch drew inspiration from earlier computer research labs while testing new interactions with working prototypes. — Metamuse: Industrial Research.
  2. Research and Product Have Different Jobs: Wiggins distinguishes exploratory Ink & Switch research from Muse’s need to become a usable, sustainable commercial product. — Muse Retrospective.
  3. Value Academic Rigor: Wiggins came to value the academic approach to understanding the past, present and future of computing alongside hands-on building. — InfoWorld Interview.
  4. Prototypes Make Research Tangible: Ink & Switch’s ideas were tested in working prototypes; Muse began as one such lab prototype. — Muse Retrospective.
  5. Publish Research Openly: Ink & Switch shares essays, projects and code so others can inspect and build on its work. — Ink & Switch Research Lab.
  6. Give Research a Different Time Horizon: An exploratory lab can work on ideas before they fit the immediate business demands of a product company. — Muse Retrospective.
  7. Mix Disciplines in Prototypes: The work that became Muse combined interaction design, engineering and research on input devices and canvas documents. — Muse Retrospective.
  8. Explore Before Commercializing: Muse’s path from research prototype to product shows that an interaction idea needs separate work to become understandable and useful to customers. — Muse Retrospective.
  9. Ideas Beyond One Product: Ink & Switch publishes its research so its approaches can inform other builders, not only a single lab product. — Ink & Switch Research Lab.

Part 8: Remote Work & Human Dynamics

  1. Design for Focused Remote Work: Wiggins emphasizes arranging remote work around sustained attention and explicit collaboration practices. — Metamuse: Remote Work.
  2. Remote Work Is Still Evolving: Wiggins treats fully remote knowledge work as an evolving practice, despite years of available communication technology. — Metamuse: Remote Work.
  3. Remote Work Trade-offs: Remote teams can access a broader talent pool, while trust-building and creative group work require deliberate effort. — Metamuse: Remote Work.
  4. Team Chemistry: Wiggins describes the energy of the right people working together on a shared problem and plan. — Metamuse: Planning.
  5. Planning Builds Working Chemistry: Wiggins stresses that a plan should help a group develop the chemistry and motivation to act together. — Metamuse: Planning.
  6. Give Decisions an Owner: Wiggins’s Heroku values assign each piece of work a responsible owner who makes the final call after considering feedback. — My Heroku Values.
  7. Planning Builds Shared Understanding: Wiggins argues that planning can be exciting because it develops a team’s collective understanding of the work. — Metamuse: Planning.
  8. Align Around the Purpose: Beyond task mechanics, planning should help the team understand and commit to the purpose of the work. — Metamuse: Planning.
  9. Build a Shared Model: Wiggins emphasizes collective knowledge so collaborators can coordinate without assuming that a written plan alone provides understanding. — Metamuse: Planning.