Can I sign up or use Careyosity™ POS right now?
Not yet. This is a public project page with a safe concept demo and feedback form—not a POS account signup, real checkout, or finished product.
Who is Careyosity POS for?
The direction includes farmers markets, craft fairs, pop-ups, boutiques, small retail stores, service counters, food trucks, cafés, bakeries, concession stands, basic restaurants, and businesses that sell both online and in person. Which groups are supported at release will depend on testing.
Is it only for market vendors?
No. Real market-day experience is the origin and design inspiration, not the boundary. The core positioning is: built from real market-day experience, designed for small businesses wherever they sell.
How could it fit a small retail store or boutique?
Retail goals include quick product search and favorites, SKUs, variants, inventory, discounts, bundles, returns, receipts, customer records, and clear reporting. These are development goals; the final release scope is not yet set.
What kind of restaurant support is being considered?
Basic food-service workflows may include modifiers, item notes, tipping, dine-in or takeout, open tabs, split payments or checks, receipts, and basic kitchen tickets or a simple kitchen display. Advanced table maps, seat-by-seat coursing, deep kitchen routing, tip pooling, complex labor tools, and advanced multi-terminal orchestration are not initial promises.
Will it connect to an existing website?
Website integrations are a goal, but no platform list is final. The intent is to connect where practical without forcing every business to replace its current site.
Will ecommerce and in-person inventory stay in sync?
Shared inventory is a major direction: in-person and online sales should use a consistent stock picture with safeguards for simultaneous orders. Exact ecommerce integrations, conflict handling, and sync timing still need validation.
Will it run in a browser?
A responsive browser experience is being explored so a phone, tablet, or laptop can participate in the same system. Final browser support, installability, and device requirements are not announced.
What about Android, iPhone, and iPad?
Android and iOS experiences are part of the direction. They could include browser-based use, installable web experiences, or native apps, but the final approach and supported OS versions have not been chosen.
Will it work offline?
Offline-friendly catalog and selling behavior is a goal because events can have unreliable service. Safe reconciliation, taxes, inventory conflicts, receipts, and especially offline card acceptance require careful provider-specific testing, so offline capability is not promised yet.
Which payment processors will it support?
No permanent processor commitment has been made. Careyosity POS is being designed around a provider abstraction layer that can support integrations such as Square, Stripe, or future providers without making any one processor authoritative for products, inventory, orders, or customers.
Which card readers or hardware will work?
No reader, terminal, cash drawer, receipt printer, scanner, or kitchen hardware list is final. Compatible devices must be selected and validated with each provider’s secured SDKs and certification requirements.
Will card numbers pass through Careyosity POS?
No raw card numbers, CVV, magnetic-stripe data, EMV data, or raw payment credentials should enter Careyosity-controlled code, logs, storage, or databases. Real payments would use provider-secured readers, SDKs, and tokenization.
Who owns the inventory and product catalog?
Careyosity POS is intended to remain authoritative for products, SKUs, variants, inventory, pricing, bundles, discounts, orders, customers, receipts, and reporting. A payment processor should not become the permanent inventory source.
Could there be a customer-facing display?
Yes, that is a concept being explored for order review, tipping, receipt choices, and provider-secured payment prompts. The final device model and capabilities are not decided.
How might receipts work?
Printed, email, text, or digital receipt options may be explored, subject to hardware, consent, privacy, and provider constraints. No particular receipt channel is guaranteed yet.
Will it handle refunds, returns, and cancellations?
Those are core transaction concepts the architecture should support through the selected payment provider while keeping Careyosity’s order and inventory records consistent. Exact permissions and workflows still need design and testing.
What about discounts and bundles?
Item and order discounts, fixed-price bundles, and quantity-based offers are part of the product direction. The concept demo includes safe examples; final promotion rules may differ.
What reporting is planned?
Useful sales, product, channel, inventory, tax, event, tender, discount, refund, and basic customer reporting are goals. The exact reports, accounting exports, and integrations are not final.
How will customer data be handled?
The goal is to collect only what a business needs, protect it appropriately, make permissions understandable, and avoid putting sensitive payment credentials in Careyosity systems. Final privacy, retention, and account controls will be documented before launch.
Will businesses own and export their data?
Data portability is part of the direction. Products, inventory, orders, customers, and reports should not be trapped behind a processor choice, but exact export formats and contractual terms are not yet announced.
How much will it cost?
No public pricing, subscription plan, processing rate, or hardware bundle has been announced. Pricing decisions will follow real validation, not precede it.
When will it launch?
There is no launch date. The current work is foundation and validation: architecture, concept testing, feedback, hardware and provider research, and real-world workflow proof.
How are privacy and security being approached?
The current public feedback flow uses Turnstile, private D1 storage, explicit contact permissions, and no automatic mailing-list signup. Product security, access control, auditing, backups, retention, and incident response will require separate design and testing before real POS use.
Are project updates automatic?
No. Project-update permission is separate, explicit, and unchecked by default. Feedback follow-up and testing interest are separate choices. Active D1 subscriber status is authoritative, and unsubscribe or suppression must be honored.
How can I volunteer for beta testing?
Choose the separate testing-contact option in the feedback form and provide an email. That records interest only; it is not a reservation, promise of access, or automatic subscription to project updates.
Are the screenshots and Software Preview real?
They are concept experiences built with mock data. The Software Preview is interactive, but it cannot take a real payment, create a production order, or touch live inventory or customer data. Every concept area may change.
Which ideas are goals, and which are promises?
Unless the page clearly says something is already working on this public project site, product capabilities are goals under exploration. Provider support, hardware, offline behavior, integrations, app availability, pricing, launch timing, and the final feature set are not promises.
Can I share feedback?
Yes. Use the feedback button from anywhere on this page. One idea is enough, and contact permissions remain optional and separate. Please do not include card details, passwords, or customer information.
