I have reached the point where another polished demo will tell me less than one honest integration attempt.
I’m building RollDate, a small family of MIT-licensed JavaScript date components. The demos work, the packages are published, and the documentation covers the public API.
But that is not the same as proving that another developer can install a package, understand the API, and use it in an actual interface without my assumptions getting in the way.
So I’m looking for five frontend developers:
- three people to test RollDate Core;
- two people to test RollDate Events.
I am not looking for stars, generic praise, or “looks nice” comments. I need to know where the integration becomes confusing, inconvenient, or impossible.
What are the two products?
RollDate Core
RollDate Core is a scroll-first date and time picker for forms, filters, booking flows, and other interfaces where a user needs to select:
- one date;
- a date range;
- multiple dates;
- a time.
It can be installed from npm:
npm install @rolldate/core
You can start with the live demo and Core documentation.
RollDate Events
RollDate Events is an event calendar with Month, Week, Day, and Agenda views. It is intended for schedules, dashboards, bookings, and applications that need to display their own event data.
Install it with:
npm install @rolldate/events
The current version does not include drag and drop, event resizing, recurring-event expansion, or resource timelines. If your task requires one of those features, rejecting the package for that reason is valid feedback.
See the Events demo and Events documentation.
What does the test involve?
Use either package in a real project or a realistic prototype. It does not need to be a production application, and you do not need to share private source code.
The useful test is simple:
- Choose Core or Events based on an interface you actually need.
- Follow the documentation before asking me for help.
- Try to render the component with your own configuration or event data.
- Stop and record the first blocker instead of fighting it for hours.
- Tell me what happened and what you expected instead.
Thirty to sixty focused minutes should be enough to expose the first integration problems. If the package fails after five minutes, that result is still useful.
What feedback do I need?
Please include:
- your framework or setup: vanilla JavaScript, React, Vue, Svelte, or something else;
- your bundler and browser;
- the interface you were trying to build;
- whether the installation and first render worked;
- the first unclear part of the documentation;
- any API that felt awkward or did not fit your data;
- bugs, missing behavior, or accessibility problems;
- whether you would keep using the package after the test—and why.
A console error, screenshot, or small reproduction is more useful than a long general review.
I especially want negative findings. If RollDate is the wrong choice for your use case, I want to understand that before building paid features on top of the wrong assumptions.
What do testers get?
RollDate is free and open source under MIT. I can help diagnose the integration after your first independent attempt, and useful findings will directly influence the documentation and roadmap.
This is not an unpaid request for a full QA cycle. I am asking for one focused integration attempt and an honest account of where it succeeds or fails.
How to participate
Leave a comment using this short format:
Product: Core or Events
Stack: framework + bundler
Use case: one sentence
I’ll reply and coordinate the test with the first suitable developers so that we cover different stacks and use cases.
You can also inspect the source or report a reproducible problem directly:
If you try it and decide not to use it, please say what made you stop. That may be the most valuable result of the test.
Top comments (0)