• 

  Takt — Plan Smarter. Prioritize Better.

• 

  Takt home overview with upcoming competitions and planning capacity.

• 

  My Schedule — manage availability, commitments, and recurring events.

• 

  Analyze Competition — submit a competition URL or PDF for analysis.

• 

  Source Review — inspect extracted competition facts and provenance.

• 

  Decision Report — review readiness, feasibility, risks, and recommendation.

• 

  Alternative Candidate Explorer — compare additional valid execution plans.

• 

  Saved Plans — track accepted plans and progress over time.

• 

  Re-evaluate — detect stale plans when competition or schedule inputs change.

• 

  Accepted Commitment — confirmed work blocks become part of the user’s schedule.

• 

  Gantt Chart - Canonical Report

Takt

Plan smarter. Prioritize better.

Takt is a calendar-aware competition decision-support system that helps people decide whether and how to pursue a hackathon or competition using evidence from the competition source, their real availability, workload assumptions, and explicit planning constraints.

It does not treat a competition URL as automatically reliable truth, and it does not turn a recommendation into a calendar commitment without the user's approval.

Takt separates the decision into distinct stages:

Competition source
→ Evidence-backed canonical brief
→ Readiness
→ User constraints
→ Workload
→ Candidate planning
→ Feasibility
→ Recommendation
→ Human decision
→ Accepted local commitment

The goal is simple: help users understand what they can realistically take on before they commit.

Inspiration

Competition decisions look simple until the information has to survive contact with reality.

A hackathon or competition can have:

• a submission deadline in a specific timezone;
• a separate registration deadline;
• eligibility requirements;
• team-size constraints;
• category-specific rules;
• required technologies;
• required artifacts;
• judging criteria;
• multiple official pages that disagree;
• or a PDF whose useful content needs native extraction or OCR.

Even after those facts are understood, a second problem remains:

Can the required work actually fit into the user's real schedule before the deadline?

Participants often answer that question informally. They skim the rules, estimate the workload mentally, compare it loosely against classes, work, organizations, sleep, and existing commitments, and then commit.

That can produce overloaded schedules, unfinished submissions, unrealistic scopes, and avoidable opportunity cost.

We built Takt to turn that vague judgment into a structured decision process.

Instead of asking only:

“Do I want to join this competition?”

Takt helps the user examine:

• what the competition actually says;
• which facts are verified, missing, unresolved, or conflicting;
• whether the user is ready to evaluate it;
• what work the selected scope requires;
• how uncertain that workload is;
• when the user can actually work;
• which schedules satisfy the hard constraints;
• how robust those schedules are under different effort scenarios;
• and why a recommendation was produced.

Takt is decision support, not an autonomous scheduling agent.

The final decision remains with the user.

What it does

Takt can ingest supported competition material from a URL or PDF and transform it into a traceable planning workflow.

The core flow:

1. captures the source and preserves provenance;
2. performs defensive URL, HTML, PDF, and OCR-capable processing;
3. extracts supported competition facts;
4. reconciles evidence into a versioned canonical competition report;
5. keeps conflict, missingness, and uncertainty explicit;
6. evaluates deterministic readiness;
7. models user availability and existing commitments;
8. validates workload estimates and task dependencies;
9. generates bounded candidate plans using OR-Tools CP-SAT;
10. independently checks candidate invariants;
11. evaluates feasibility across explicit workload scenarios;
12. assembles an advisory recommendation;
13. lets the user inspect the system-primary plan and valid alternatives;
14. requires explicit confirmation before a plan becomes an accepted local commitment;
15. preserves accepted history and supports re-evaluation when material inputs change.

Takt helps answer questions such as:

• What does this competition actually require?
• Are any critical facts still missing or conflicting?
• Am I ready to evaluate this opportunity?
• How much work does the selected scope require?
• Does that work fit into my real availability?
• Which candidate schedules are valid?
• What happens if the workload takes longer than expected?
• Is the plan feasible, tight, or infeasible under the current constraints?
• What trade-offs does the recommendation depend on?
• Has the previous recommendation become stale?
• Which parts of the result are facts, assumptions, or recommendations?

The output is a structured Decision Report rather than a single unexplained score.

Core decision flow

The end-to-end lifecycle is:

URL / PDF
↓
Source snapshot
↓
Native extraction / OCR evidence
↓
Candidate extraction
↓
Reconciliation
↓
Canonical competition report
↓
Readiness
↓
Availability + workload
↓
CP-SAT candidate plans
↓
Feasibility
↓
Recommendation
↓
Decision Report
↓
Explicit user action
↓
Accepted local plan / progress
↓
Re-evaluation when material inputs change

Several distinctions remain intentionally separate throughout the flow:

source evidence != canonical truth
canonical brief != readiness
readiness != feasibility
feasibility != recommendation
recommendation != commitment
stale history != current truth

Operational flowchart

The operational flowchart shows how the system handles validation, extraction, reconciliation, readiness, planning, recommendation, persistence, recovery, and human authority.

Important runtime boundaries include:

• invalid or unsupported source input stops before planning;
• missing information remains missing instead of becoming false information;
• conflicting evidence remains conflict unless deterministic authority or freshness rules justify supersession;
• blocked readiness does not become solver infeasibility;
• technical failure does not become a domain conclusion;
• only valid availability can be used for planning;
• task dependencies and daily capacity constrain candidate schedules;
• a solver candidate is independently validated before it can support a recommendation;
• recommendation remains advisory;
• accepted truth exists only after explicit user action and successful local persistence.

Takt can therefore finish with uncertainty, review, tight capacity, infeasibility, or a supported recommendation instead of forcing every case into a positive answer.

System architecture

Judge-facing architecture

The simplified architecture keeps the main responsibility boundaries visible:

Flutter mobile client
↓
REST / JSON
↓
FastAPI compute layer
↓
Source processing
↓
Canonical reasoning
↓
Planning + feasibility
↓
Recommendation
↓
Human decision
↓
Local-first persistence

For the current MVP:

DEVICE = personal state
SERVER = compute

The backend primarily performs computation and decision-support evaluation.

The mobile application owns personal state and accepted-plan persistence.

Full technical architecture

The full architecture expands the same flow into implementation-oriented components:

• Flutter presentation and local state;
• SQLite + Drift persistence;
• RevenueCat entitlement boundary;
• FastAPI product API;
• Pydantic public contracts;
• URL and PDF ingestion;
• native extraction;
• OCR;
• evidence reconciliation;
• readiness;
• availability;
• workload;
• OR-Tools CP-SAT scheduling;
• feasibility;
• recommendation;
• re-evaluation;
• public failure contracts;
• explicit human acceptance.

The architecture deliberately avoids making a cloud database part of backend correctness for the MVP.

Takt also avoids treating monetization state as decision truth. RevenueCat can control access to a presentation feature, but it cannot change competition facts, readiness, solver results, feasibility, or recommendation correctness.

Data strategy

Takt uses a contract-first data strategy.

The project deliberately separates source evidence, deterministic fixtures, future behavioral data, and product runtime state because they answer different questions.

1. Real public source corpus

Real competition sources are used for:

• URL and PDF extraction evaluation;
• canonical-field validation;
• provenance evaluation;
• source conflict evaluation;
• extraction and reconciliation testing.

These sources are evaluation evidence, not a custom-model training dataset.

The source hierarchy is:

1. official legal or rules source;
2. official organizer source;
3. official event or platform page;
4. official FAQ or update;
5. secondary source;
6. synthetic fixture for evaluation only.

The system preserves source identity, extraction path, evidence locators, and versioned provenance so downstream decisions can be traced back to supporting evidence.

2. Synthetic deterministic and adversarial fixtures

Synthetic fixtures are used where deterministic truth is more useful than pretending to have field data.

They cover areas such as:

• calendar constraints;
• recurrence and exceptions;
• overlapping commitments;
• fragmented capacity;
• CP-SAT invariants;
• native-versus-OCR reconciliation;
• missing fields;
• conflicting sources;
• hard feasibility cases;
• fallback and recovery behavior;
• stale-state transitions;
• release screenshots.

Synthetic fixtures are explicitly treated as:

EXPERIMENTAL
NOT SOURCE OF TRUTH
NOT FINAL TRAINING DATASET
NOT PRODUCT EVIDENCE OF REAL-WORLD OUTCOMES

They are engineering evidence.

3. Future real behavioral and outcome data

Real behavioral data is intentionally deferred until the product can collect defensible observations.

Examples include:

• actual task effort;
• estimate-versus-actual history;
• recommendation usefulness;
• accepted, edited, or ignored recommendations;
• completion risk;
• long-term calibration.

Synthetic acceptance labels are not treated as evidence of recommendation quality.

4. Dataset families

The preproduction data strategy defines several dataset families:

• DS-01 Source Understanding Corpus for authoritative-source extraction and provenance;
• DS-02 Calendar Constraint Fixtures for schedule and recurrence behavior;
• DS-03 Solver Feasibility Fixtures for task, dependency, capacity, and buffer invariants;
• DS-04 Task Effort Dataset for future effort-estimation work;
• DS-05 Recommendation Evaluation Dataset for future real-user evaluation.

The current MVP does not require a custom-trained ML model to make its decision.

5. Leakage policy

Takt treats leakage as a methodology failure, not a cosmetic benchmark problem.

Examples of forbidden leakage include:

• using actual effort before task execution;
• using final completion state to predict initial feasibility;
• using future calendar changes in an earlier recommendation;
• using label-derived variables to predict the same label;
• splitting near-duplicate versions of the same competition source across evaluation partitions.

Where grouped evaluation is required, related entities remain together.

For example:

• source extraction groups by source_family_id or competition_id;
• OCR variants group by original document;
• future unseen-user effort evaluation groups by user_id;
• deterministic solver fixtures use fixture families rather than train/test terminology.

6. Calibration and uncertainty

Takt explicitly models uncertainty instead of manufacturing precision.

The system distinguishes:

• source uncertainty;
• effort uncertainty;
• constraint uncertainty;
• recommendation uncertainty.

For workload, the MVP uses:

minimum
likely
maximum

rather than a single forced estimate.

Before any future user-facing probability is introduced, the data strategy requires:

• a defined empirical target;
• held-out calibration measurement;
• reliability analysis;
• appropriate probabilistic metrics;
• and distribution-shift review.

The current release therefore avoids unsupported claims such as “87% feasible.”

7. Custom-model training gate

A custom-trained model is allowed only after:

• the target definition is stable;
• prediction-time features are documented;
• leakage audit passes;
• split strategy is frozen;
• baselines and metrics are defined;
• sufficient real labels exist;
• uncertainty and calibration plans exist;
• deterministic rules remain authoritative;
• rollback is possible.

The current release candidate does not include a custom-trained ML model.

That is deliberate.

The MVP relies on explicit contracts, deterministic readiness rules, transparent workload ranges, and CP-SAT planning where those methods match the problem better.

Logical data model

The logical ERD represents the relationships behind the complete decision-support lifecycle.

At a high level, the data model connects:

• source records;
• extracted evidence;
• canonical competition reports;
• canonical field states;
• readiness results;
• availability;
• commitments;
• tasks;
• workload ranges;
• candidate plans;
• feasibility results;
• recommendations;
• evaluation basis;
• stale transitions;
• accepted plan revisions;
• task progress;
• and traceability metadata.

The model keeps source evidence, user constraints, planning state, recommendation state, and accepted state as separate responsibilities.

That separation matters because Takt is not storing a generic to-do list.

It preserves the chain from:

what the competition says

through:

what the user can realistically do

to:

why a particular recommendation was produced

and finally:

what the user explicitly chose to accept.

Why the system separates the decision stages

Each stage answers a different question.

Source processing

“What evidence did we receive?”

Takt captures and processes the source without assuming extracted text is already canonical truth.

Reconciliation

“What competition facts can we responsibly publish?”

Supported observations are reconciled into canonical fields with explicit states such as:

VERIFIED
SINGLE_SOURCE
CONFLICT
MISSING
UNVERIFIED

A conflict cannot become a usable fact merely because one extraction path has a higher confidence value.

Readiness

“Do we know enough, and does the case satisfy the deterministic conditions needed to evaluate it?”

Readiness remains separate from feasibility.

Examples of readiness outcomes include:

READY_TO_EVALUATE
NEEDS_REVIEW
ELIGIBILITY_BLOCKED
DEADLINE_PASSED
INSUFFICIENT_INFORMATION

Unknown eligibility is not the same as failed eligibility.

Workload

“What work does the selected scope require?”

Tasks can preserve:

• identity;
• mandatory status;
• dependencies;
• minimum effort;
• likely effort;
• maximum effort;
• assumptions.

The workload layer validates:

• minimum <= likely <= maximum;
• duplicate IDs;
• dependency references;
• dependency cycles;
• deterministic topological order;
• transitive required closure.

Availability

“When can the user actually work?”

Availability is modeled as timezone-aware, minute-aligned intervals.

The system can account for:

• work windows;
• fixed commitments;
• flexible commitments;
• recurrence;
• exceptions;
• accepted project commitments;
• daily capacity;
• focus-duration preferences;
• target buffer.

Aggregate free hours alone are not enough. Ten continuous hours and twenty thirty-minute fragments are different planning states.

Candidate scheduling

“Which concrete schedules satisfy the hard constraints?”

OR-Tools CP-SAT is used to generate bounded candidate allocations.

Planning respects:

• available-only scheduling;
• task dependencies;
• finish-to-start semantics;
• deadlines;
• daily capacity;
• task splitting rules;
• scheduling buffers;
• candidate diversity constraints.

Candidate output is independently checked against invariants instead of trusting solver output merely because the solver returned a result.

Feasibility

“How does the plan behave under different workload assumptions?”

Takt evaluates explicit workload scenarios, including:

MIN
LIKELY
MAX
FULL_SCOPE

Feasibility can distinguish:

FEASIBLE
FEASIBLE_WITH_TRADEOFFS
TIGHT_CAPACITY
NOT_FEASIBLE_UNDER_CURRENT_CONSTRAINTS

A technical execution failure is not represented as infeasibility.

Recommendation

“Given the validated evidence above, what decision-support output should be presented?”

The recommendation can expose:

• recommended candidate identity;
• suggested work windows;
• rationale;
• trade-offs;
• assumptions;
• valid alternatives.

The recommendation does not independently override source truth, readiness, or feasibility.

Re-evaluation

“Has the evidence or planning basis materially changed?”

Takt preserves distinct states such as:

UNCHANGED
SUPERSEDED
SESSION OUTDATED

Trusted stale evidence is not silently erased.

A previous accepted plan remains historical truth even when the evaluation that produced it later becomes stale.

Explicit acceptance

The final authority boundary is:

Recommendation
↓
User confirms
↓
Local transaction commits
↓
Accepted truth exists

A failed persistence operation does not become an accepted plan.

A suggestion is not a commitment.

Local-first persistence

The Flutter application uses SQLite + Drift for personal state.

Persistence covers release-critical state such as:

• schedule commitments;
• recurrence and exceptions;
• analysis snapshots;
• accepted plan revisions;
• accepted schedule blocks;
• task progress;
• stale evaluation state.

The backend remains primarily a stateless compute layer.

This architecture avoids introducing server-side persistence before there is a concrete need for:

• accounts;
• cross-device synchronization;
• shared team workspaces;
• cloud backup;
• asynchronous server jobs;
• server-side accepted-plan history.

RevenueCat / Takt Pro

RevenueCat is used as an access boundary, not a correctness boundary.

Canonical Shipaton identifiers include:

entitlement: pro
Test Store product: takt_pro_lifetime_v1
offering: default
package: $rc_lifetime
premium feature: alternative_candidates

The free experience keeps:

• competition facts;
• readiness;
• feasibility;
• the system-primary recommendation;
• and other correctness-critical domain information.

An active pro entitlement unlocks the Alternative Candidate Explorer, allowing the user to inspect and select additional valid candidates already returned by the same backend evaluation.

RevenueCat does not change:

• source provenance;
• canonical facts;
• readiness;
• planning inputs;
• candidate validity;
• solver output;
• feasibility;
• recommendation correctness;
• accepted-plan history.

Unknown or initial entitlement failures fail closed for the premium-only surface.

Refresh failures preserve the last trustworthy entitlement state.

Purchase and restore use RevenueCat's official Flutter SDK.

The Shipaton demo path uses RevenueCat Test Store configuration.

How we built it

We used an evaluation-first, contract-driven process.

The project moved through:

Discovery and Problem Framing
↓
Product Requirements
↓
Evaluation and Domain Rules
↓
Data Strategy
↓
Synthetic Evaluation Fixtures
↓
Preproduction Contracts
↓
Implementation Handoff
↓
Production Implementation
↓
Integration
↓
Reliability Work
↓
Backend Release Audit
↓
Mobile + End-to-End Release Audit
↓
Release-Candidate Closure

Before implementation, we defined the behavior that needed to remain stable:

• canonical source semantics;
• readiness states;
• workload invariants;
• availability rules;
• task dependencies;
• feasibility semantics;
• recommendation boundaries;
• human acceptance authority;
• stale evaluation behavior;
• recovery classes;
• persistence semantics.

That let us test the system against explicit contracts instead of treating a successful demo as proof of correctness.

The production stack includes:

Backend
- Python 3.12
- FastAPI
- Pydantic v2
- httpx
- python-multipart
- OR-Tools CP-SAT
- PyMuPDF
- Tesseract OCR

Mobile
- Flutter
- Dart
- Provider
- SQLite
- Drift
- http
- file_picker
- timezone
- RevenueCat purchases_flutter

Quality
- pytest
- Ruff
- flutter_test
- GitHub Actions
- uv

Evidence and evaluation

Takt's release process treats evidence as part of the product rather than an afterthought.

Backend release audit

Hari 7A completed a full backend release audit.

Audited backend runtime freeze:

650d17ff8dabed273ab50ef5d60581697b777367

Recorded backend gate:

Python Ruff       PASS
Python regression 1010 passed
0 failed
0 skipped
known P0          0
known HIGH        0

The audit covered:

• URL ingestion;
• PDF ingestion;
• native extraction;
• OCR;
• source provenance;
• candidate normalization;
• reconciliation;
• canonical report integrity;
• readiness;
• availability;
• workload;
• CP-SAT planning;
• independent candidate validation;
• feasibility;
• recommendation;
• re-evaluation;
• public API failure semantics.

Mobile and end-to-end release audit

Hari 7B completed the mobile and end-to-end release audit.

Audited mobile runtime/evidence freeze:

ab44fbe1776afe1a04adeb028aaef6c0e2017622

Exact-head CI recorded:

Flutter analyze                 PASS
Flutter regression              286 passed
320 px / 2x compact QA          PASS
9 screenshot evidence states    PASS
390 × 844 crop verification     PASS
Android debug build             PASS
iOS debug build                 PASS

The mobile audit covered:

• root navigation;
• schedule CRUD and recurrence;
• Analyze Competition;
• source review and provenance;
• Decision Report;
• alternative candidate presentation;
• explicit acceptance;
• Saved Plans;
• task progress;
• stale and re-evaluation behavior;
• recovery;
• local persistence;
• responsive critical-path QA;
• Android and iOS debug builds.

Release-candidate closure

Both release audits are merged.

Current release-candidate blocker count:

P0 / critical = 0 known
P1 / HIGH     = 0 known

The release candidate is ready for submission packaging within its documented claim boundary.

Challenges we ran into

Source truth is harder than text extraction

Extracting characters from HTML or PDF is only the first step.

The harder problem is determining whether multiple observations agree, conflict, represent the same instant in different timezone notation, come from independent sources, or should remain unresolved.

Takt therefore separates extraction from reconciliation.

Ambiguous source facts

A single source can contain repeated or contradictory values.

During the backend release audit, ambiguity handling was tightened so the parser fails closed rather than silently selecting the first supported value.

Equivalent timezone instants can still reconcile, but contradictory or partially unsupported alternatives are not silently promoted to canonical truth.

Unknown is not infeasible

A missing eligibility attribute, incomplete brief, or technical failure should not become a false negative decision.

Takt keeps these meanings separate:

UNKNOWN != INFEASIBLE
FAILURE != MISSING
EMPTY RESULT != FAILURE
CONFLICT remains CONFLICT

Free time is not planning capacity

A total-hour calculation can claim that a project fits even when the work cannot actually be scheduled.

Dependencies, fragmentation, recurring commitments, deadlines, daily limits, and focus blocks matter.

That turned planning into a constraint-satisfaction problem rather than simple arithmetic.

Workload is uncertain

One exact estimate creates false precision.

Takt therefore uses minimum, likely, and maximum effort ranges and evaluates multiple scenarios.

Solver output still needs verification

A solver returning a candidate is not enough.

Candidate plans are independently checked against hard invariants before they can support feasibility or recommendation.

Recommendation is not commitment

The product must not silently convert a suggested window into an accepted commitment.

Acceptance requires explicit confirmation and a successful local transaction.

Stale state is real state

When inputs materially change, the previous evaluation can become stale.

But stale historical truth must not be erased.

Takt preserves trusted SUPERSEDED evidence and accepted historical revisions instead of rewriting them as if the earlier decision never happened.

Monetization can contaminate correctness if designed badly

RevenueCat could easily have been wired into recommendation behavior.

We deliberately prevented that.

Entitlement controls access to the Alternative Candidate Explorer, not the truth of the analysis.

Accomplishments that we're proud of

We are proud that Takt turns a vague question:

“Should I join this competition?”

into a traceable workflow:

Evidence → Canonical Brief → Readiness → Workload → Availability → Candidate Plans → Feasibility → Recommendation → Explicit Acceptance

The release candidate combines:

• URL and PDF source intake;
• native extraction;
• OCR;
• source provenance;
• evidence reconciliation;
• explicit canonical field states;
• deterministic readiness;
• minute-based availability;
• recurrence and exceptions;
• dependency-aware workload models;
• minimum / likely / maximum effort;
• OR-Tools CP-SAT candidate generation;
• independent candidate invariant validation;
• multi-scenario feasibility;
• traceable advisory recommendations;
• multiple valid candidate plans;
• RevenueCat-gated alternative candidate exploration;
• local-first SQLite + Drift persistence;
• accepted-plan revisions;
• task progress;
• stale-state preservation;
• re-evaluation;
• explicit recovery semantics;
• Android and iOS mobile builds;
• backend and mobile release audits.

We are especially proud that correctness boundaries remain visible in the product:

CONFLICT != VERIFIED
UNKNOWN != INFEASIBLE
FAILURE != MISSING
recommendation != commitment
entitlement != correctness

What we learned

We learned that useful decision support depends less on producing a confident answer and more on preserving the structure behind the answer.

A recommendation becomes more useful when the user can inspect:

• the evidence;
• the unresolved facts;
• the workload assumptions;
• the available capacity;
• the candidate plan;
• the feasibility classification;
• the trade-offs;
• and the reason the recommendation exists.

We also learned that abstention can be a valid product output.

CONFLICT, MISSING, UNKNOWN, NEEDS_REVIEW, TIGHT_CAPACITY, and explicit infeasibility preserve information that a forced answer would destroy.

Another lesson was that optimization should be used only for the part of the problem it actually owns.

CP-SAT is good at finding schedules under constraints.

It does not determine whether the competition source is trustworthy, whether eligibility is known, whether a recommendation should become a commitment, or whether a paid user deserves a different truth.

Keeping those responsibilities separate made the system easier to audit.

Known limitations

The current release candidate intentionally does not claim:

• general multilingual competition-rule understanding;
• a general-purpose LLM extraction system;
• perfect extraction from arbitrary websites;
• universal live-source extraction accuracy;
• a custom-trained ML decision model;
• production authentication;
• production rate limiting;
• production load certification;
• Railway network or egress-policy certification;
• signed Play Store distribution;
• signed TestFlight distribution certification;
• live RevenueCat store-transaction certification;
• cross-device synchronization;
• shared team workspace;
• cloud backup;
• server-side accepted-plan persistence;
• automatic calendar execution;
• exhaustive physical-device certification;
• support for every locale, accessibility mode, device ratio, or OEM environment.

Additional boundaries include:

• the production candidate normalizer uses a bounded explicit grammar;
• unsupported ambiguity fails closed rather than guessing;
• OCR is bounded, but not every synchronous PDF operation is forcibly terminated at one exact global wall-clock threshold;
• CI screenshots are Flutter-renderer evidence, not exhaustive real-device validation;
• unsaved in-memory state is not guaranteed to survive arbitrary OS process death;
• the current file_picker Android integration emits a future Flutter/Kotlin compatibility warning while the audited Android debug build still passes.

These are documented limitations, not hidden promises.

What's next for Takt

The next phase should improve the quality of evidence rather than simply add more automation.

Priorities include:

• broader source-language and competition-format coverage;
• richer canonical extraction where it can be validated safely;
• stronger multi-source competition reconciliation;
• collection of real estimate-versus-actual workload history;
• real recommendation usefulness evaluation;
• calibration of future workload estimation from real data;
• calendar integrations that preserve explicit user authority;
• cross-device synchronization when a concrete account model exists;
• team-based planning;
• longer-horizon portfolio planning across multiple competitions;
• production RevenueCat store validation;
• production authentication and deployment hardening.

A future learned effort-estimation model should only be introduced after sufficient real labels, leakage controls, baselines, calibration, and rollback criteria exist.

The point is not to turn Takt into a larger pile of automation.

The point is to make the next decision more defensible.

Try it

Hosted API:
https://takt-production-951d.up.railway.app

iOS TestFlight:
https://testflight.apple.com/join/PEfUw9CX

Demo video:
https://youtu.be/aa_vFMYPgjU

Source code:
https://github.com/panjiaryasoma/Takt

---

Takt

Plan smarter. Prioritize better.

Preserve the source. Keep uncertainty explicit. Model the real constraints. Let the human decide what becomes real.

Built With

• dart
• drift
• fastapi
• flutter
• httpx
• or-tools
• provider
• pydantic
• pymupdf
• pytest
• python
• revenuecat
• ruff
• uv
• uvicorn