Proboot Start today
Available nowIn beta

Start

Orders, shipping and money in order from day one, without reorganising the shop floor.

Orders and customers

An order is taken the way the wholesaler dictates it: as a size run.

  • Customers, contacts, order history
  • Orders by size run
  • Models without tech cards
  • Order statuses, partial fulfilment
  • Stock reserved for the order

Packing and finished goods warehouse

The finished goods warehouse is built by the packer's scanner, not a spreadsheet.

  • Labels with a serial number on every pair
  • Finished goods stock is built from the packer's scans
  • Finished goods stock count with a discrepancy report
  • Stock by model, size and colour

Shipping

Waybill, delivery note and invoice are created from the shipment card, no retyping.

  • Nova Poshta waybills from the system
  • Delivery note, invoice
  • Cartons: what is in which
  • Shipping history per customer

Money

See who paid how much, who owes you and how much you earned on each order.

  • Payments, partial payments, prepayments
  • Customer debts, due dates, overdue amounts
  • Discounts and price types for customers
  • Any currency, exchange rate on the document date

Also in the Start plan

Staff, SMS and API

  • Everyone works under their own account and sees only what their role needs
  • Activity log: who changed what and when
  • The SMS links to an online invoice: total, payment, balance due and parcel tracking
  • SMS to the customer about order status and dispatch with the waybill
  • API: orders, finished goods stock, customers, shipments
  • Webhooks for new orders and status changes
Beta from January 2027

Workshop

Actual cost of every model, not the norm.

Materials and components

Leather arrives in batches at different prices and is accounted for exactly that way.

  • Catalogue of materials and components with their properties
  • Receipts from suppliers, batches at their own price
  • Returns to suppliers
  • Material use for non-standard needs
  • Materials stock count
  • Stock by batch, not by average

Tech cards

A model is described once, with norms for every size and every stage.

  • Tech card by stage: cutting, stitching, assembly
  • Consumption norms for every material
  • Size grids, size runs for uppers
  • Colour variants of a model

Production

Work is split into batches, and you can see where each one is and who has it.

  • Work and route sheets
  • Batches: pairs that move through the workshop together
  • Issuing materials to a stage
  • Material requirements for an order
  • Shortages and what to buy

Cost

What a pair really cost, not what it should have cost by the norm.

  • Actual cost per pair
  • Overuse against the norm
  • Consumables and period overheads
  • Deviations from norms by model

Payroll

Pay is calculated from the completed work employees hand in through the system.

  • Piece-rate by model and stage
  • Fixed salary
  • Salary plus piece-rate
  • Payroll statements
Beta from January 2027

Factory

Manage sections and teams, not just models.

Sections and teams

With several workshops, accounting runs by section and team, not just by model.

  • Several sections within one stage
  • Teams
  • Rate per stage, for a whole team or for each member

Warehouses and semi-finished goods

Materials, uppers and finished goods across several warehouses, with transfers between them.

  • Several warehouses of each type
  • Remote warehouses and sites
  • Transfers between warehouses with a transfer record
  • In-house semi-finished goods as an accounting unit
  • Selling semi-finished goods to others, with their cost
Q4 2027

Group

Several factories, one picture.

Several factories in one account

The owner sees all their factories together, and each team sees only its own.

  • Several factories and legal entities in one account
  • Consolidated group reporting
  • Permissions by factory and legal entity
  • Priority support

Security

Orders, costs, prices, customers, salaries: this is data that must not reach third parties. Below is exactly how Proboot protects it: no marketing generalities, just specific settings.

In short

  • Every factory's data is isolated at the database level, not only in the application code.
  • Passwords are stored with argon2id, a modern standard that resists brute force on graphics cards.
  • Sign-in with a second factor and passkeys: a code from an app, or face, fingerprint or PIN.
  • Support enters your system only the way you allow, and you see every such login.
  • Daily encrypted backups that the server itself cannot decrypt.
  • All connections go over HTTPS only (TLS 1.2 and 1.3), and the database and internal services are closed to the internet.

Sign-in and accounts

  • Passwords. Stored with argon2id. It is deliberately slow and memory-hungry, so guessing a password is practically impossible even on powerful graphics cards. Outdated fast hashes such as SHA-256 give no such protection.
  • Password rules. At least 8 characters, upper and lower case letters, a digit and a special character.
  • Second factor (2FA). A code from an authenticator app and 10 one-time backup codes in case you lose your phone. You have 5 minutes and 5 attempts to enter a code. The second factor can be turned off only with the password plus a code.
  • Passkeys. Sign in without email or password: by face, fingerprint or device PIN. Such a sign-in already counts as two-factor. A passkey can be added or removed only from a session opened with a second factor.
  • Brute-force protection. After 10 failed sign-in attempts for one email, or 50 from one address within 15 minutes, sign-in is temporarily blocked. The same limit applies to password reset emails.

Session and data protection

  • Server-side sessions. They can be closed instantly. The "Sign out on other devices" button ends every session except the current one. Changing or resetting the password closes all sessions automatically.
  • Protected cookies. The session cookie is not accessible to page scripts, is sent only over HTTPS and is never sent from other sites.
  • Screen lock. A separate password or PIN that must differ from the account password. Handy when several people share one computer in the warehouse or workshop. After 5 failed attempts the session is closed.
  • Database-level isolation. Every row in the database belongs to a specific factory, and access to it is locked by PostgreSQL security policies (Row-Level Security). Even if the code has a bug, the database will not hand one factory's data to another.
  • Double check. On top of the database policies, every query is also restricted by the factory ID.

Support access under your control

Proboot team access to your system. You choose the access mode under "Settings → Security".

  • Access closed: support cannot get in at all. When access is needed, you get a "Proboot team access request" with "Allow" and "Decline" buttons. You set how long the permission lasts: 1, 4, 8 or 24 hours.
  • View only: support can look, but the server rejects any changes. If something needs fixing, support sends you a request straight from the session.
  • Access without confirmation: view only or view with edits, sessions from 30 minutes to 4 hours, and an email to you about every login.

In every mode:

  • every support login requires a reason and a separate confirmation with the support person's code or passkey;
  • you see an ongoing session: an icon with a timer, the reason for the login and an "End" button;
  • support logins, logouts and every change are recorded in your log;
  • support cannot change the access mode, sign-in methods or screen lock, even in a session with edits.

The system sees only general statistics, without your customers', orders' or money data.

Server and network

  • HTTPS. TLS 1.2 and 1.3 only, HSTS, HTTP/2. The server does not accept outdated protocols.
  • Browser protection. The Content Security Policy (CSP) allows only Proboot's own scripts to run. The system cannot be embedded in someone else's page to spoof its buttons. Plus nosniff, COOP, Referrer-Policy and Permissions-Policy headers.
  • Key encryption. Integration keys for stores and delivery services, as well as second-factor secrets, are stored encrypted in the database (AES-256-GCM). One-time codes and tokens are stored only as hashes. The interface shows only a mask.

Backups

  • Daily. A database copy is made every day and kept on the server for 7 days.
  • Off the server. Another copy is sent daily to a separate device outside the data centre, where weekly snapshots are kept.
  • Encrypted. Backups are encrypted. Even if someone gains access to the server, they cannot read them.

Questions about security, or need extra documents for your security team? Write to support@proboot.app and we will answer in detail.

Start
today

Start is available now and free while the beta lasts. Workshop and Factory from January 2027.

Country code +380

By pressing "Send request" you agree to the Privacy policy.