Paydae began with a fairly ordinary business need: preparing payroll without making the surrounding work more difficult than it needed to be.
The aim was not to invent employee records, payslips or payroll calculations. Practitioners already work with those every day, using established applications, spreadsheets and processes they have refined over time. We wanted to take a closer look at how that work fits together, particularly when someone needs to move from preparing a period to checking it and producing the resulting records.
That internal project has become Paydae Desktop, a Zimbabwe-first payroll workspace for businesses and the professionals who support them. The public beta is now available for Windows from the download page. Our current focus is learning from beta testing and using that evidence to improve the product. [S33]
Starting with the work, rather than the feature list
A payroll feature list can tell you that an application stores employees, calculates deductions and produces reports. It tells you less about what happens between those tasks.
Can the person reviewing an employee’s pay see the relevant context without repeatedly leaving the screen? Is it clear which inputs belong to this period and which belong to the employee’s ongoing record? Can a reviewer distinguish an unexplained movement from an expected change? After completion, is it clear which records belong to the finalised period?
Those are the questions guiding the product. A capability is only useful when its execution helps someone complete the work with confidence.
For example, an overview table should remain useful for scanning a payroll. Opening an employee’s details should add the context needed to investigate, rather than replace the overview with a disconnected sequence of forms. The design task is to make those views work together.
Why Zimbabwe comes first
We are starting with a defined payroll context because a credible workflow needs more than a list of tax percentages. Employee classifications, currencies, reporting requirements and the way practitioners prepare submissions affect the work around the calculation. ZIMRA’s employee-management and earnings processes are one example of that connection. [S34]
Beginning with Zimbabwe gives the team a more specific set of questions to test with professionals. Does the terminology make sense? Are the required records available at the point they are needed? Is the path from a calculation to an output understandable? Where does someone still have to leave the workflow to reconstruct information?
We are not presenting a Zimbabwe-first product as a finished solution for every jurisdiction. Broader ambitions should follow demonstrated understanding, not get ahead of it.
Built with professional workflows in mind
An employer running its own payroll and a consultant supporting several clients share some tasks, but their working contexts are different.
A consultant needs to stay oriented when moving between organisations. The current client, period and status should be unmistakable. An employer may be more concerned with a clear monthly routine and a straightforward handoff to an accountant or approver.
Paydae’s multi-organisation direction reflects that distinction. We want the product to support repeated professional work without treating every client as though it has identical arrangements. The detailed experience, limits and available functions should be assessed in the actual beta build, rather than inferred from a broad description.
A local-first starting point
Paydae Desktop is being built around a selected local workspace and deliberate outputs. That is a product choice about where day-to-day payroll work takes place, not a claim that local storage removes every security or operational responsibility. [S33]
A local workspace still needs appropriate device access, a reliable backup process and a tested route to recovery. Producing a file also creates a new copy of information whose destination needs consideration. These responsibilities should be understandable, not hidden behind the phrase “your data”.
There are tradeoffs. A locally held workspace is not automatically a shared, real-time collaboration environment. Online submissions still require access to the relevant external service. Our explanation of local-first payroll sets out those distinctions in more detail.
What we want the beta to establish
The most valuable feedback will not be limited to whether a screen looks good. It will show whether a professional can complete a representative task, understand the result and recover from an interruption or mistake without losing the thread.
We want to learn from the ordinary cases as well as the difficult ones: a new employee, a changed allowance, an unusual movement, an output that needs checking and a record that must be found again later. Where a workflow is not yet available or is being evaluated in a prototype, that should be stated explicitly.
A beta is not evidence that every operational scenario has already been covered. It is a structured opportunity to test the product against the work it is intended to support. Real payroll use needs a confirmed scope, appropriate safeguards and clear agreement about limitations.
What comes next
We will use this resource library to share practical payroll explanations as well as the thinking behind the product. Those articles should be useful in their own right, including to people who never use Paydae.
For the product, the immediate task is more specific: improve the coherence of the workflow, test the important transitions and listen carefully when practitioners show us where the design interrupts their work.
That is the approach behind Paydae. Not a claim that payroll needs to be rediscovered, but a commitment to making the execution more considered.
References
- S33 · Paydae — Paydae official website. Checked 2026-10-27.
- S34 · ZIMRA — Submission of PAYE return through Employee Management Module. 2025 guidance.