Services · Calendar and scheduling audit
Calendar and scheduling audit, then the fixes
We review your product's calendar, scheduling and booking features end to end, write down what's broken or fragile, and then fix it in reviewed pull requests with tests.
Request a scheduling auditRead the sample report
- Starts with
- A written scope of what is in and out
- You get
- A written assessment, then fixes as pull requests with tests
- Price
- Set by the written scope, agreed before work starts
Booking code tends to look fine in a demo and break at the edges. We check:
- availability against connected calendars;
- time zones and daylight saving changes;
- two people booking the same slot;
- reschedules and cancellations for each role;
- calendar sync.
You get a written assessment of what’s broken or fragile, then fixes as reviewed pull requests with automated tests around the scheduling logic.
Is this a fit?
Who it is for
Startups and small software teams whose product books time, shows availability or syncs with other calendars, and who want it checked before launch or before more users arrive.
Problems it solves
- Bookings an hour off around a daylight saving change or an untested time zone.
- Two people able to book the same slot.
- Availability that doesn’t match the person’s own calendar, or a sync that works in one calendar app only.
How to request it
- Open the request form; this service is already selected.
- Say what your product schedules, which calendars it connects to, and where your team suspects problems.
- Thomas replies by email. After a short call or a few written questions, you get a written scope and price before any work starts.
Free checklist. Pre-launch QA checklist: the checks we run, written so your team can run them on its own product before launch. No email needed.
Proof from our own demonstration
Numbers from a demonstration on an application we built with invented data. It is labelled as a demonstration, not client work, and the defects planted on purpose are disclosed.
- 75 of 75automated checks passing after the review, up from 48 of 75
- 8 of 8logged defects fixed and verified by retest
- 3 rolestested end to end, on desktop and at phone width
Situations this fits
Scheduling code often looks fine in a demo and breaks at the edges. Situations like these:
- Bookings that land an hour off for some users, usually around a daylight saving change or a time zone nobody tested.
- Two people able to book the same slot at the same time.
- Availability that doesn’t match what the person’s own calendar says.
- A calendar sync or feed that works in one calendar app and not in another.
- No automated tests around the scheduling logic, so every change feels risky.
What the audit covers
- Availability logic: working hours, buffers, blocked time, and how conflicts are detected.
- Self-serve booking: the path a user takes to pick a time, confirm it, reschedule and cancel.
- Time zones: how times are stored, converted and shown, including daylight saving changes.
- Calendar sync and feeds: connections to outside calendars, and any calendar files or feeds your product publishes.
- Automated tests: what the existing tests cover, and where scheduling behavior isn’t tested at all.
What you receive
- A written assessment. Each defect and fragile area, with steps to reproduce, what happened, what should have happened, and how serious it is.
- Fixes as pull requests, each with tests, for the findings you assign to us.
- Tickets in your tracker, so the findings live where your team already works.
- A retest of every fix, recorded against the original ticket.
- A weekly written progress note.
What this does not include
So the scope is clear from the start:
- Changes made directly in production. Work happens in staging, and production access only if you grant it in writing.
- Merging our own changes. Your team reviews every pull request before it’s merged.
- A guarantee that the scheduling code is free of defects. The audit covers the agreed scope.
- IT support, hosting or marketing. We focus on auditing, testing and fixing software.
How the work runs
- Scope. We agree in writing which features, calendars and environments are in, and which are out.
- Audit. We read the code and exercise the features in staging, then write up what we find.
- Fix. We fix the findings you assign to us, each as a pull request with tests.
- Retest. Every fix is retested against the original finding before the ticket is closed.
How we work with your team
The same rules apply to every engagement:
- Staging only. We work in a staging environment. We have no production access unless you grant it in writing.
- Every change is a pull request. Your team reviews it before it’s merged.
- Tickets in your tracker. Findings and fixes live where your team already works.
- A weekly written progress note: what’s done, what’s next, and anything blocked.
- AI tools only on accounts that don’t train on your data. Credentials and bulk data never go into AI tools.
Ownership and handover
The aim is code and tests your team can maintain without us.
- Your repository. Fixes, tests and documentation go into your own repository through your normal review.
- Ownership. Code written specifically for you becomes yours once it is fully paid for, subject to the signed agreement. Our preexisting tools and code, and third-party materials, are not transferred.
- After launch. There is no automatic fix period. Support after launch is available only under an agreed contract.
What moves the cost
There is no fixed price list, because cost follows scope. These are the things that usually make an audit larger or smaller:
- How many calendar providers, feeds and time zones the product supports.
- How much of the scheduling logic is covered by tests today.
- How many user roles can book, block or change time.
- Whether a staging environment with test calendars is ready, or needs setting up.
- How many findings you want us to fix, not only report.
Who’s accountable
Thomas Wagenberg, founder. He scopes and leads every engagement and signs off every finding. Testing and fixes use AI-assisted engineering under his direction, and every change reaches you as a pull request your team reviews.
Wagenberg Technology Group serves startups and small software teams remotely across the United States, with a focus on Cleveland and Fort Lauderdale.
Where and how we work
We work remotely with teams across the United States, including teams in Cleveland and Fort Lauderdale. Pricing depends on the scope of the project, which we agree in writing before work starts.
For teams in Cleveland and Northeast Ohio: software audits and launch-readiness reviews for Cleveland and Northeast Ohio.
Tell us what you’re launching
Describe the product and what worries you about it. Thomas will reply by email.
In your request, say what your product schedules, which calendars it connects to, and where your team suspects problems.