ProgressOS

ProgressOS connects measurable goals—including revenue and order targets—to the services where progress happens, so real-world data updates progress instead of manual check-ins.

Comment

Competition section: Personal Finance

The idea

Traditional goal trackers require users to manually report progress. ProgressOS connects goals to the services where progress actually happens, allowing measurable goals—including financial and business goals—to update from real-world data.

ProgressOS is a broader goal operating system with a particularly strong small-business financial use case. A seller can set a goal such as “complete 100 Shopify orders in 60 days” or “reach $5,000 in current Shopify order value,” connect an authorized read-only Shopify source, and see the value, sync freshness, history, and goal status update from verified provider data. In the current test-store demonstration, connected goals show 54 of 100 orders, $3,923 of $5,000 in current order value, and 52 of 100 products.

What it does

A user defines an outcome, then reviews an explicit measurement contract before creating it: provider, resource, metric, comparison, target, baseline, and time window. ProgressOS synchronizes the provider value, stores timestamped measurement history, and shows whether the goal is on track, complete, stale, or unable to sync.

This makes the goal auditable. An unavailable integration is not displayed as zero, a provider failure is not presented as success, and absolute targets remain mathematically distinct from improvement relative to a baseline.

ProgressOS also supports non-financial goals, multi-goal creation, provider management, and a browser-extension companion. The finance-focused entry demonstrates Shopify revenue, orders, current order value, products, and related verified Shopify metrics. It does not claim bank, brokerage, investment-account, credit-score, or transaction-aggregation integrations.

Why it is unique

A spreadsheet can model a target but must be updated manually. A single-provider dashboard shows numbers but does not understand the user's goal. An automation tool can move data but usually does not model target semantics.

ProgressOS combines all three layers: human intent, an explicit metric contract, and evidence from the source system. Its core differentiator is simple: a goal tracker should measure the evidence, not ask the user to become its data-entry clerk.

That approach gives ProgressOS a market advantage as a provider-neutral goal layer that can sit above the tools people already use. Users keep the operational systems they trust while gaining a consistent language for targets, baselines, comparisons, time windows, freshness, and history.

How it was built

ProgressOS uses Next.js 16, React 19, TypeScript, Auth.js, PostgreSQL, Drizzle ORM, and Zod. A provider-adapter architecture separates goal logic from external services. Shopify measurements use read-only Admin GraphQL access. Sync jobs are idempotent, retry failures with bounded backoff, and preserve timestamps, attempt state, baselines, current values, metric windows, and measurement history.

Voice goal creation runs a bundled whisper.cpp WebAssembly model inside a browser worker, so audio stays in the browser. The transcript is interpreted with deterministic parsing and shown for review before saving; the goal path does not rely on a cloud LLM or autonomous agent.

The deployed staging service runs on Render with PostgreSQL and configured object storage. A Cloudflare Workers, D1, and R2-compatible build path also exists.

Feasibility and completion

ProgressOS is an existing project presented here in its current, substantially functional state; it was not built specifically for Coppell Hackathon 1.

Fresh verification completed successfully across the product: 1,295 main tests, 99 extension tests, and 23 Playwright end-to-end flows passed. TypeScript checks, ESLint, extension and production builds, and live health/readiness checks also passed. The staging environment has verified live Shopify test-store metrics and measurement history. This is working software, not only a concept or design prototype.

Challenges

The hardest engineering work was keeping metric definitions consistent across parsing, review, validation, storage, and sync; preserving the distinction between absolute and baseline-relative targets; handling provider errors without showing fake success; and keeping OAuth credentials server-side, encrypted, and limited to read-only scopes. Shipping useful local speech recognition also required careful attention to browser download size and memory use.

Business model and potential to make money

A realistic potential model is freemium:

  • a free consumer tier for manual goals and a limited connection;
  • a premium individual subscription for advanced integrations, automated sync, alerts, and longer history;
  • an eventual team/business tier for shared goals, permissions, reporting, and workflow automation.

These are proposed business models, not claims of current revenue or traction. Initial customers could include independent sellers, student founders, creators, and small teams that want financial accountability without maintaining another spreadsheet.

What was learned

Reliable financial accountability depends on provenance and freshness as much as the displayed number. A goal becomes more useful when a user can see where its value came from, when it was measured, what failed, and how the target is calculated.

What's next

Next steps include richer comparison and forecasting views, shared team goals, more owner-approved read-only providers, stronger alerting, and completing provider-review and public-launch requirements. Personal-finance sources would be added only after least-privilege, privacy, security, and regulatory review.

Built With

Share this project:

Updates