We built a flexible goal system from identity to engineering, delivered as a responsive web app and installable PWA with cloud accounts, progress views and billing workflows.
Explore the work01The opportunity
Reading daily, walking weekly and saving toward a yearly target do not fit the same tracker. A useful system needs to respect the cadence and measure of the goal.
We built around daily, weekly, monthly and yearly horizons, with flexible measures for counts, time, distance and completion. Our hypothesis: a clearer relationship between action and progress makes a goal easier to maintain.
How could we make a flexible system feel simple enough to use every day?
Choose a daily, weekly, monthly or yearly goal.
Use the unit that fits the activity.
Update progress with touch-friendly controls.
Review progress and adjust the next step.
02From zero to one
We shaped the idea, created its identity, designed the experience and built the system that makes it work.
Goals that fit real life. The product choices, visual language and architecture developed together. Our research combined product, domain and technical exploration to shape the decisions below.
We framed the product around a goal’s cadence, unit and progress, rather than a single rigid habit format.
We explored grouping, progress controls, long and short horizons, reminder preferences and installation behavior across browser platforms.
We created a bee identity, warm yellow and ink palette, friendly copy and pastel goal cards that make progress feel approachable.
We designed goal creation, grouping, reordering, updates and analytics, adapting desktop controls to touch layouts and bottom sheets.
We built a responsive React and TypeScript web app plus a PWA manifest, branded icons, install detection and platform-specific instructions.
We connected Supabase authentication, data and Realtime with server functions, Stripe payments and SendGrid reminder implementation.
A complete brand identity
We built a friendly identity around steady progress. The bee makes the product recognizable, while a quieter interface keeps goals and their next actions easy to see.
We created a connected identity system: logo, character, color, typography, iconography and interface patterns, then carried it into the website and distribution materials.
03Product judgment
What we chose, why it mattered and what it cost.
Daily, weekly, monthly and yearly cadences work with counts, duration, distance, completion and custom units. A shared goal model supports different activities while familiar cards and progress controls keep the interface consistent.
Flexibility increases the number of states to design and validate. Defaults and reusable patterns keep that complexity out of everyday updates.
Groups and progress views connect small updates to the longer horizon. We designed analytics as a way to understand the pattern of activity, rather than treating every unfinished goal as the same kind of failure.
More context needs careful hierarchy. The next useful action stays close, while the wider view is available when someone wants it.
We built an installable progressive web app with a standalone manifest, branded icons, install detection and platform-specific guidance. The interface can move from a browser tab to an app-like home-screen experience without a separate native codebase.
Install support differs by browser. The service worker is network-only; we do not promise general offline use or offline synchronization.
04Platforms & architecture
React and TypeScript power the responsive browser experience across desktop, tablet and mobile. The same application supplies the installable PWA.
A manifest, standalone display mode and platform-aware installation flow give GoalBee a home-screen presence. Responsive navigation and touch controls adapt the experience to each viewport.
Supabase supports accounts and cloud data; server functions handle protected business logic. PWA installation does not turn the current network-only service worker into an offline sync engine.
October 2026 captures of the actual GoalBee application and install components in an isolated offline demo harness. Goals and progress are synthetic. The installation image shows guidance, not a verified installed-device session.
The responsive client captures cadence, units and progress.
Authenticated functions and ownership policies bind data to an account.
Payment webhooks update entitlements; reminder functions use user preferences.
The working stack
| Layer | Tools | Purpose |
|---|---|---|
| Responsive experience | React · TypeScript · Vite | A shared web application with desktop, tablet and mobile layouts. |
| Cloud & server | Supabase Auth · Postgres · Realtime · Edge Functions · Hono | Account data, updates and authenticated business logic. |
| Commerce & reminders | Stripe Checkout / Portal / signed webhooks · SendGrid | Server-owned subscription state and reminder delivery implementation. |
| PWA delivery | Web manifest · Service worker · Install prompt APIs | Standalone presentation, branded icons and platform-specific install instructions. Network connectivity remains necessary. |
Security is product work
We built account boundaries, server-controlled billing and consent safeguards as part of GoalBee’s security foundation. These support readiness work; GoalBee has no independent SOC 2 attestation.
SOC 2 is an independent examination of an organization’s controls against trust services criteria. Aligned controls and readiness work do not equal an auditor’s SOC 2 report, and “certified” would misstate our status. About SOC 2
The server verifies access tokens and ownership instead of trusting client identifiers.
Clients cannot grant themselves premium access; signed payment events drive plan state.
Analytics consent, separate default-off marketing preferences and consent records support explicit choices.
A managed platform helps with infrastructure; AS1 still owns application access, data policies, secrets and integration decisions. A provider’s SOC 2 report does not cover our application automatically. Supabase’s shared responsibility model
05Brand, marketing & distribution
We made the brand promise concrete through goal horizons, flexible measures and visible progress, using the same friendly identity as the app.
We connected identity, messaging, product education and acquisition. Conversion means helping the right visitor reach the next useful action, then measuring whether that action leads to value.
Visit the GoalBee websiteGoal and habit use-case content, page titles, descriptions, canonical URLs, structured data and sitemap coverage support search entry into the web product.
The landing page explains the goal model and offers a route into the browser app. Goal creation and a first progress update are more useful activation goals than an account count alone.
GoalBee is a web app and installable PWA. Browser entry, platform-specific home-screen installation and web subscription flows cover distribution without presenting it as a native App Store release.
From discovery to first value
Discover a use case or the landing page.
Enter the web app and create an account.
Set a goal and update meaningful progress.
Install the PWA and build a repeat routine.
We would measure entry-to-goal creation, first updates, repeat logging, installation and paid insights demand. The conversion story remains a testable plan, not a claim of uplift.
06Delivery & learning
We delivered the product system described here. Product-market fit has not been established.
These case studies show our ability to connect brand, product, design and engineering. The next stage is to establish adoption, paid demand and customer outcomes.
Daily, weekly, monthly and yearly.
One responsive product and codebase.
Brand, product, design and cloud engineering.
What the build taught us
A shared web foundation can cover many devices without a native rebuild. The important work is adapting interactions and stating the limits of the platform honestly.
The next validation
We need to validate repeated progress logging, goal follow-through, PWA adoption and willingness to pay. Illustrative progress charts are product demonstrations, not evidence of improved outcomes.
The right team for the stage
We can take a product from idea to a working release, including its brand, frontend, managed backend and integrations.
The team model should evolve with the risk and demands of the business.
Before market fit is proven, scope and direction change quickly. Where appropriate, Supabase gives us a practical managed foundation. We can own application data models, authentication, backend functions and integrations while iterating on the product.
We recommend a lead responsible for data architecture, backend reliability, infrastructure and cybersecurity, working with AS1 on brand, product and design. Supabase may remain the right platform; scale calls for stronger engineering ownership, not an automatic rewrite.
Health-tech, fin-tech and other sensitive products: involve specialist engineering and security leadership from discovery. Data sensitivity, regulatory duties and operational risk can require that collaboration before market fit or rapid growth.
Your idea could be next
Bring us the problem, the people it serves and the stage you’re at. We’ll help shape a focused path from idea to product.
Discuss your project