Skip to main content
Golux Group

LifeCopilot: Answering Whether the Deadline Is Real

LifeCopilot: Answering Whether the Deadline Is Real

A project execution system that forecasts the date instead of counting completed tickets, because a task board can be green on a project that is going to be late.

Open the live product
  • Application
  • Backend
  • Frontend
Location
Belgrade, Europe
Team
Golux Group
Project type
Web application · AI product
Year
2026

Business challenge

Project tools record intention well and go quiet on the only question a stakeholder asks, which is whether the date holds. Percentage complete is counted in tickets, so a board shows eighty per cent while the remaining twenty per cent contains all of the hard work. Tasks are written at whatever size someone felt like, which means a card can sit in progress for two weeks without anyone being able to say why.

What we did

A brief is decomposed into goals, milestones and tasks, with every task sized between fifteen minutes and three hours, which is small enough that a stalled one is visible within a day. Dependencies, estimates and blockers are first-class rather than labels. Progress is effort-weighted instead of counted, and observed velocity drives a forecast against the committed date, so the product states whether the deadline is reachable rather than leaving it to be felt. An AI copilot reads the plan itself, drafts tasks, finds the gaps between a milestone and the work underneath it, and answers questions from the project's own data.

What shipped

  • Goals, milestones and completion criteria stay linked to the work beneath them
  • Every task sized between fifteen minutes and three hours, with dependencies and blockers made explicit
  • Effort-weighted progress and a velocity-based forecast against the committed date
  • An AI copilot grounded in the project's own plan and data rather than a general chat window

How we built it

The starting point was an uncomfortable observation about our own work. Every project tool we had used could show what was done and none of them could say whether the date would hold. The information needed to answer that was already in the system. Nothing was using it.

The first decision was therefore about task size, which sounds like a detail and is actually the whole foundation. If tasks are written at arbitrary sizes, velocity means nothing and a stalled card is invisible for weeks. Capping tasks between fifteen minutes and three hours makes estimation honest and makes a blockage visible within a day. Every other feature depends on that constraint holding.

Then the structure above it: goals and milestones with real completion criteria, so there is a definition of done before there is a task list. Dependencies and blockers made structural rather than cosmetic, so the critical path is derived instead of argued about. Those are modeling decisions, and they were made on paper before the schema.

Forecasting came after the structure, because it can only be as good as the data underneath. Progress weighted by effort rather than counted, observed velocity against committed dates, and a product willing to say the date is not reachable. That last part is a product decision more than an algorithm, and most tools avoid it because nobody enjoys being told.

The AI copilot was deliberately last. It reads the plan, drafts tasks, finds the gap between a milestone and the work underneath it, and answers from the project's own data. Adding that before the structure existed would have produced a chat window attached to a task list, which is the mistake the whole category is currently making.

The method, in order

  1. Start from the question nobody answers

    Not what is missing from competitors, but what the user actually needs to know and cannot find out. Here it was whether the date is real.

  2. Fix the unit of work

    Fifteen minutes to three hours, enforced. Without a consistent unit, velocity is noise and every number built on it is decoration.

  3. Model the structure before the schema

    Goals, milestones, completion criteria, dependencies and blockers decided on paper. Modeling mistakes are cheap on paper and expensive in a database.

  4. Earn the forecast

    Forecasting shipped only once the data underneath could support it. A forecast from bad data is worse than no forecast, because people act on it.

  5. Add AI where there is context to read

    The copilot came last and works from the project's own plan and data. It is useful because there was already something worth reading.

Built with

  • React
  • TypeScript
  • PostgreSQL
  • LLM APIs

For your product

What we would do on your product

We run engagements the way this product works. The plan is broken down to a size where a problem is visible in days, progress is reported against effort rather than activity, and if a date is moving you hear it the week it starts moving. No status theater, no surprise at the end. If you want to see the method before committing to anything, the free audit is the shortest way to find out how we think.

Run the free auditSee the product we built

Questions people ask

Why does task size matter so much?
Because it is the unit everything else is measured in. Inconsistent sizes make velocity meaningless, and a card that is really three weeks of work can sit in progress without anyone being able to say why.
Why build forecasting last?
Because a forecast is only as good as the structure underneath it, and a confident wrong forecast is worse than none. People make commitments on it.
Do you run client projects this way?
Yes. Small units of work, effort weighted progress, and a date that is reported honestly while there is still time to react to it.
What does the AI actually add?
It reads the plan rather than the world. Drafting tasks, finding gaps between a milestone and the work beneath it, and answering from project data. The value comes from the structure it has to read, not from the model.

What the work covered

  • Backend development
  • Frontend development
  • Product design
See everything we do

Your project

Want an outcome like this one?

Start with a realistic budget and timeline for your own product, or bring the problem straight to the engineer who would work on it.

Calculate project costBook a strategy call

Keep going

Where to go next

The engineering notes

What we find inside AI-built apps.

The findings from the apps we audit, the fixes that worked, and what each one cost, written by the person who did the work. No roundups, no reposts.

A few emails a month. No spam, unsubscribe any time.

Golux Group

Already a client? Golux Club
is where your project lives: tickets, approvals, files, one record.

Open