Video summary

288. The Best Approach for Building a Large Web Application

Main summary

Key takeaways

Educational

Main ideas, concepts, and lessons

  • Start with clear, written scope and planning

    • Define what “Version 1” includes and what future enhancements might include.
    • Avoid relying on verbal agreement or assumptions (misremembering what was agreed can become costly).
    • Ensure everything is documented whether you’re a consultant or an internal team.

  • Build only the “minimum viable” Version 1, then expand

    • Version 1 should be no more than the MVP (or essentially the MVP).
    • Avoid trying to deliver all desired features in the first release—this can delay deployment for many months/years and make the product outdated before users see it.
    • Maintain a future enhancement list so you can say “not for V1” but still track it for later.

  • Use rough sketches to align expectations early

    • Create an extremely rough UI/flow sketch (physically or sketch-style digital) and walk stakeholders through it.
    • The goal is to get sign-off on workflows and structure while everyone understands it’s not a finished product.
    • Avoid “too-real” drag-and-drop or polished mockups, because they create false expectations about readiness/timeline (stakeholders may think it’s almost done).

  • Build a “vertical slice” (a thin but complete end-to-end prototype)

    • Treat it like a game-dev vertical slice: include a little of everything, not a full system.
    • For a web app, a vertical slice should cover core workflows such as:
      • Authentication
      • Small-scale data access
      • Some UI/display
      • Basic styling/structure
      • Example: one login page plus one sample authenticated page
    • Purpose:
      • Test key engineering decisions early (data access approach, CSS/layout patterns, page structure).
      • Establish patterns to replicate across the rest of the app.
      • Keep changes cheaper by validating foundations early.
    • Gather feedback immediately (internal team + external users/stakeholders).

  • Scale from the vertical slice by parallelizing work

    • Once the slice works, assign team members to build additional pages/features using the slice as the north star/pattern reference.
    • This enables parallel development while maintaining consistent architecture and approach.
    • Process framework choice (Scrum vs waterfall) is secondary; the key is delivering small working parts and iterating.

Best practices

  1. Write clear plans for V1 and future enhancements

    • Put decisions in writing.
    • Specify what the first release is and what is explicitly deferred.
    • Use documentation as a checklist and expectation anchor.

  2. Keep Version 1 near MVP

    • Release a working product early.
    • Add enhancements only after learning from real feedback and needs.
    • Maintain a future enhancement list.

  3. Sketch/roughly draw the product before building

    • Use very rough visuals to align stakeholders.
    • Prefer tools/mediums that look clearly unfinished (e.g., pencil/legal pad or sketch tools like Excalidraw).
    • Walk stakeholders through interactions and flows.
    • Avoid high-fidelity mockups that mislead about progress.

  4. Build a vertical slice

    • Include end-to-end fundamentals (auth + data access + UI).
    • Use it to:
      • Validate foundational choices (architecture, CSS, data patterns).
      • Provide a concrete target for feedback.
      • Reduce later rework.
    • Get feedback early while changes are cheap.

  5. Keep improving from there (parallelize using the slice)

    • Divide work once patterns exist.
    • Ensure everyone builds consistently from the slice.

  6. Put as little as possible on a page

    • Avoid dumping large datasets into UI components (e.g., grids containing huge numbers of records).
    • Show only what users need to do their next action.
    • Load more detail only when the user performs the next step (e.g., when viewing/working the selected item).

  7. Keep things simple

    • Default to simpler architectures and avoid “complex because we might need it later.”
    • Don’t build for “Google scale” prematurely.
    • Complexity can slow down delivery and harm the customer experience.

  8. Keep dependencies light

    • Every dependency increases risk.
    • Example: left-pad removed from npm → many apps broke due to unnecessary reliance.
    • Use dependencies only where truly necessary.
    • Prefer consolidating around fewer vendors/maintainers instead of many different ones.

  9. Get feedback as early as possible

    • Validate UI/design preferences (colors, fonts).
    • Validate functional choices early (auth method, login approach).
    • Make changes before too much is implemented.

  10. Use documented plans as guidelines and protection

    • Use written scope to:
      • Determine what “done” means.
      • Push back when new demands appear.
      • Negotiate timeline and scope adjustments if something new is requested.

Pitfalls to avoid

  1. Scope creep

    • Adding features “because it’s faster” is still scope creep.
    • Treat new requests as new work; discuss tradeoffs and timeline.
    • Put deferred items into the “next list” (future enhancements), not into the current build.

  2. Changing technology midstream

    • Avoid switching frameworks/libraries during development unless required.
    • Upgrading late can cause rework and delay the release.
    • Exception case described: major breaking change scenario (example: AngularJS → Angular 2 transition) where the speaker chose to finish rather than rewrite.

  3. Doing too much in the first version

    • Don’t try to include everything “essential.”
    • Trying to pre-bake everything can lead to a never-released product (“the never version”).
    • Add features incrementally after something working is deployed.

  4. Complexity without enough added value

    • Avoid overengineering approaches like unnecessary microservices.
    • Microservices can add:
      • Complexity and operational overhead
      • Performance overhead (network calls within distributed systems)
      • Harder debugging (more systems to trace)
    • Only adopt added complexity if it provides clear extra value.

Speaker / sources featured

  • Tim Corey (host/speaker; closes with “Thanks for listening… I am Tim Corey.”)
  • No other named individuals were featured.
  • Reference example mentioned (as a real-world case):
    • left-pad (npm package) and its maintainer dispute (not a named person in the subtitles beyond “the author”).
  • Tool mentioned:
    • Excalidraw (specifically recommended for sketch-style diagrams).

Original video