Interactive demo · Week 1 of every prototype

Prototype preview before we actually build it.

Meet Munch, a connected pet feeder and its phone app. Neither exists, but the firmware and the app logic do, running right here. On real projects, Atallis builds a preview like this from your idea in the first week, so we can argue about behavior before anyone argues about parts.

The story behind Munch

  1. The idea

    A feeder you can trust from a hotel room

    Maya travels for work two nights a week. Her cat Biscuit doesn't. She wants meals on time, a snack when she misses him, and a ping on her phone if anything goes wrong.

  2. Week 1 · First preview

    "He'd press that button all day"

    Before a single part is ordered, Maya gets a link. Within minutes she spots it: Biscuit will learn the button. We add a daily snack limit. Here it's a dropdown; after tooling, it's a firmware release.

  3. Week 1 · The real question

    What if the internet drops while she's away?

    Keep feeding, or wait? We decide together: the feeder runs on its own clock, stores what happened, and syncs when it's back. The app says "offline" honestly instead of pretending.

  4. Week 2 · The case nobody planned

    A jammed motor means a hungry cat

    The preview forces us to write down the exact behavior: stop the motor, blink red, and tell Maya how many portions actually went out. That sentence becomes a requirement for the hardware.

Device

  • Breathing blue: online
  • One blinking LED: no Wi-Fi
  • Amber: food low
  • Red: jam or empty

Press the button on the lid for a snack · Drag to rotate

Phone app
7:57●●● ▮
Biscuit's feeder
Food in hopper62%
Next meal
Schedule
Activity

    Test conditions

    Change the spec

    Each of these is a product decision. Here it costs one click; after tooling, it costs a board revision.

    Event log

      Fictional founder, real process.

      By the end of week two, Maya has approved how Munch behaves by clicking it, not by reading about it, and the schematic starts from that. Maya and Munch are fictional, but the process is very representative of the early phase of working with Atallis: we keep documentation to what's useful and demo as much as we can. A long spec gets skimmed. A preview gets clicked, and every click settles a question while it's still cheap to change the answer.

      I like surprises. Just not on your project ;-) Better to find them here in week one than on the bench in week eight.

      Start a project →

      What is a prototype preview?

      A prototype preview is a clickable simulation of how your product will behave, built before any hardware exists. It runs the same logic the firmware and the app will run: states, buttons, lights, alerts, schedules and connectivity. You, your team and your future users try it in a browser, on any device.

      At Atallis, the preview is built in the first week of a prototyping engagement, from the discovery call and your notes. It is not a separate product to buy. It is how the engagement starts.

      What it catches early

      • Behavior nobody wrote down. What happens when the internet drops, the battery runs low, two commands arrive at once, or a user presses the button ten times.
      • Device and app disagreements. Which side is the source of truth, what the app shows while the device is offline, and how events sync back.
      • Failure modes. Jams, empty states, sensor faults: what the device does, what the user sees, what gets logged.
      • Product limits. Daily caps, timeouts, alert thresholds. Each one becomes a line in the spec instead of a surprise on the bench.

      Where it fits in the process

      Week 1: we plan together, then you get a first preview of the behavior. Weeks 2 to 3: the preview evolves as decisions are made, and the hardware architecture starts from the behavior you approved. Weeks 4 to 7: the physical prototype is built and tested against the same scenarios the preview made explicit.

      We keep documentation to what is useful. A long spec gets skimmed; a preview gets clicked, and every click settles a question while it is still cheap to change the answer.

      What you get

      • A link you can share with your team, investors or test users.
      • A behavior spec written from the scenarios you approved, not from assumptions.
      • Test scenarios reused later to check the physical prototype.

      What it does not replace

      A preview models behavior, not physics. Battery life, radio range, motor torque, thermal limits and EMC still have to be measured on real hardware. The preview makes sure that when we measure, we already agree on what the product should do.

      Questions about prototype previews

      Is the preview the real firmware?
      No. It reproduces the firmware logic (states, timings, rules) in the browser so it can be tested before hardware exists. The production firmware is written for the actual microcontroller, using the preview behavior as its spec.
      Does a preview cost extra?
      No. On Atallis prototyping engagements, the preview is part of the first phase, not an add-on.
      Can my users or investors try it?
      Yes. It runs in any modern browser, on desktop or phone. Sharing a link is often the fastest way to collect feedback before committing to a design.
      Which products is it useful for?
      Anything whose behavior matters as much as its electronics: connected devices with an app, products with buttons, lights or screens, instruments with modes and alarms. It helps least when the main risk is purely physical, such as sensor accuracy or radio range.
      Is Munch a real product?
      No. Munch and Maya are fictional, built to show the process. Client previews stay confidential under NDA.

      You have the idea.
      Let's make it real.

      One conversation is enough to know if we're a fit. No jargon, no commitment, just an honest look at what it takes to build your prototype.

      Start a project → See capabilities