Drew Rangers Tracker Pro: building software for a real team workflow

Real workflow changes the design

Building a team operations app is different from building a clean portfolio demo.

A demo can optimize for screenshots. A real workflow has to survive repeated use, imperfect data, different roles, and moments where the user is not calmly exploring the interface. A basketball staff member might need a practice report, roster update, injury note, or game-day workflow quickly.

Drew Rangers Tracker Pro was built around that kind of practical constraint.

Public evidence

This project has public source code at Basketball-Team-Manager. The code is useful evidence because the project is not only a mockup. It has real workflow categories, Cloudflare deployment choices, data persistence, scheduled work, and reporting concerns.

For a portfolio, that matters more than a polished screenshot. The interesting part is whether the system reflects how a team actually operates.

The product surface

The app supports several operational areas:

• practice workflow
• game-day workflow
• admin console
• health and injury flow
• roster sync
• PDF report generation

The stack is intentionally web-native: Vue 3, Vite, Tailwind, Cloudflare Pages Functions, Cloudflare D1, Worker Cron, Node test runner, and PDF generation.

The key design challenge is not making one page beautiful. It is making the app predictable across many small workflows.

Why roles matter

Operational software usually becomes confusing when every user sees every action.

The practice workflow, health flow, admin console, and reporting tools should not feel like one giant page. They should feel like separate work modes that share the same data foundation.

That pushed the product toward role-oriented screens. A user should know:

• where they are
• what action is available
• what data was last updated
• what can be exported or reviewed
• what belongs to another workflow

This sounds basic, but it is the difference between a usable internal tool and a dashboard that only the builder understands.

Infrastructure choices

Cloudflare was a good fit because the project needed a lightweight deployment surface, serverless functions, scheduled work, and a database layer that did not require heavy infrastructure management.

Cloudflare D1 is not the answer to every data problem, but it fits small-to-medium operational apps well when the data model is clear and the app benefits from being close to the edge deployment platform.

The most important habit is to keep the schema boring. Roster data, reports, health notes, and game records should be explicit. Clever abstractions can make the app harder to debug.

Data model discipline

Operational apps become painful when the data model tries to be too clever. I would rather have clear tables and predictable fields than a flexible abstraction that nobody trusts after two weeks.

The categories in this project are intentionally plain:

• roster records
• practice records
• game-day records
• health or injury notes
• generated reports

Those names are not fancy, but they match the user's mental model. That is usually the right tradeoff.

Reporting as product

PDF generation is easy to treat as an afterthought. In an operations app, reporting is often the product.

If the app collects practice and game information but cannot produce a clean artifact for review, the workflow is incomplete. A report is how the software leaves the screen and enters a meeting, message, or archive.

That means report layout, export reliability, and clear labels matter as much as the main interface.

What I would improve next

The next version should make historical review stronger. Once a team has enough records, the app can help answer operational questions:

• Which practice notes keep repeating?
• Which players need follow-up?
• Which game-day issues are recurring?
• Which reports should be compared over time?

That would move the product from record keeping toward decision support.

What I learned

This project reminded me that full-stack engineering is mostly about respecting the work people are already doing.

The software should not ask a team to reorganize itself around the database. It should model the team's real categories: practice, game, health, roster, admin, reports.

The best compliment for this kind of app is not that it looks clever. It is that a user can open it under time pressure and immediately know what to do.