Pumasi — writing

Why does sending a 500KB PDF cost $45 a month? The DocuSign tax and pure-edge stamping

2026-08-30T00:00:00Z

Sending an agreement and collecting a signed PDF is computationally trivial: place vector ink or typed text at designated coordinates, compute a cryptographic digest, and store the resulting 500KB file. Yet incumbents have turned this basic computer science primitive into one of the most aggressive tollbooths in enterprise software. --- ## 1. The Incumbent Business Model: Artificial Scarcity DocuSign does not sell compute or storage. It sells **artificial envelope scarcity**. ``` ┌─────────────────────────────────────────────────────────┐ │ THE $7,200/YEAR DOCUSIGN TOLLBOOTH │ │ 20 Employees · Standard plan · annual billing │ │ Figures read from DocuSign's own page, 2026-08-31 │ └───────────────────────────┬─────────────────────────────┘ │ ┌───────────────────────────────────┼───────────────────────────────────┐ ▼ ▼ ▼ ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────┐ │ Per-Seat Tax │ │ Envelope Metering │ │ Above Business Pro │ │ $30 – $45 / user / mo │ │ 100 envelopes / user │ │ "Enhanced Plans" │ │ Standard · Bus. Pro │ │ / year, both plans │ │ price not published — │ │ ($7,200–$10,800 / yr) │ │ Personal: 5 / month │ │ "contact sales" │ └───────────────────────┘ └───────────────────────┘ └───────────────────────┘ ``` ### What Businesses Actually Pay Let us look at published pricing vs. the real invoices small-to-medium businesses face: | Provider | Published Tier (Per User) | Monthly Allowance | Gated Features | Annual Cost (20 Users) | | :--- | :--- | :--- | :--- | :--- | | **DocuSign** ([Pricing](https://ecom.docusign.com/plans-and-pricing/esignature), read 2026-08-31) | **$30 – $45** / user / mo (Standard, Business Pro; annual billing) | **100 envelopes / user / yr**, as shown on both plans | Reusable templates, signer attachments, SSO gated to Enterprise | **$7,200 – $10,800** / yr | | **Pumasi Sign** ([pumasi.ai](https://pumasi.ai/products/pumasi-sign/)) | **$0.00 (Unmetered)** | **Unlimited Envelopes** | **All features included · Custom Branding.** Licence: the repository carries no `LICENSE` file yet — see the product page | **$0.00 / yr** | **On the sourcing of that table, because it has been corrected twice.** The DocuSign row was re-read from the vendor's own pricing page on **2026-08-31** and matches `pumasi-sign` [`roadmap/MARKET.md` §1](https://github.com/pumasi-ai/pumasi-sign/blob/main/roadmap/MARKET.md); it previously read "$25 – $40", which was wrong at both ends. **This table used to carry an Adobe Sign row and a PandaDoc row. They have been removed rather than restated.** They held this post's original figures, which nobody here had read from either vendor. Neither vendor appears in any product repository's `MARKET.md`, so there was no owned source to check them against, and on **2026-08-31** both vendors' own pricing pages refused to serve us a price: `adobe.com/sign/pricing.html` returned no response body over repeated requests, and `pandadoc.com/pricing/` answered `HTTP 429` behind a JavaScript bot challenge. An unread number is not a weaker citation than a read one; it is not a citation. The two annual columns derived from those rows are gone with them, because arithmetic on an unverified figure reads as more precise than its input, not less. The measured reason to distrust the dropped rows is the row beside them: the DocuSign figures of exactly that provenance were wrong at **both** ends when someone finally opened the page. Prices move, and the date is part of the claim. When a growing business hires 5 new team members on the Standard plan, their e-signature bill increases by $150 per month — even if those employees send one offer letter a quarter. --- ## 2. Why Incumbents Claim It Must Be Expensive Incumbents justify these fees with two claims: 1. *"Legal compliance is complex and requires specialized proprietary infrastructure."* 2. *"Document rendering and PDF manipulation require heavy server compute."* Both claims are historically outdated. ### The Legal Reality: ESIGN and eIDAS Under the US **Electronic Signatures in Global and National Commerce Act** ([15 U.S.C. § 7001](https://www.law.cornell.edu/uscode/text/15/7001)) and the European Union's **eIDAS Regulation** ([Regulation (EU) No 910/2014](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG)), an electronic signature is legally binding if four requirements are satisfied: 1. **Intent to Sign**: Demonstrable physical or digital action affirming agreement. 2. **Consent to Electronic Records**: Notice and affirmative acceptance to do business electronically. 3. **Association of Signature with Record**: The signature data must be deterministically stamped and tethered to the exact document bytes. 4. **Tamper-Evident Retention**: An audit certificate recording timestamps, IP addresses, user agents, and cryptographic digests proving the document was not altered post-execution. None of these requirements require a $45/user/month per-seat subscription. They require standard cryptography (`SHA-256`) and deterministic coordinate geometry. --- ## 3. The Technical Breakthrough: Pure Edge PDF Stamping Legacy e-signature architectures run heavy virtual machines executing Python or headless LibreOffice instances to flatten and rasterize PDFs. This creates massive operational overhead and cold starts. In **Pumasi Sign**, document stamping is implemented as a **pure TypeScript / WebAssembly engine** running entirely inside Cloudflare V8 worker isolates: ``` ┌────────────────────────────────────────────────────────────────────────────────────────┐ │ PUMASI SIGN: PURE EDGE ARCHITECTURE │ ├────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ [ Client Browser ] │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────────────────────────┐ │ │ │ Cloudflare Edge Worker (sign.pumasi.ai) │ │ │ │ │ │ │ │ 1. Normalized Coordinate Geometry: │ │ │ │ (x_page, y_page) = (x_rel · PageWidth_pt, (1 - y_rel) · PageHeight_pt) │ │ │ │ │ │ │ │ 2. In-Memory Vector Stamping (pdf-lib / V8 Isolate): │ │ │ │ • Embeds high-res PNG / SVG vector ink directly │ │ │ │ • Appends Cryptographic Signature Certificate Page │ │ │ │ │ │ │ │ 3. SHA-256 Cryptographic Audit Proof: │ │ │ │ • Hash_original = SHA256(Raw_Upload_Bytes) │ │ │ │ • Hash_completed = SHA256(Stamped_Output_Bytes) │ │ │ │ │ │ │ │ 4. Transactional SQLite Storage (Durable Objects): │ │ │ │ • Envelope state, multi-signer tokens, audit logs, binary PDF blobs │ │ │ └──────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ [ Tamper-Evident Executed PDF with Audit Trail (Instant Download) ] │ │ │ └────────────────────────────────────────────────────────────────────────────────────────┘ ``` ### The Math: Normalized Coordinates Across Dynamic Viewports Different devices render PDF pages at different scale factors. Mobile phones, Retina displays, and 4K monitors have distinct CSS pixel densities. Pumasi Sign avoids coordinate drift by computing all field placements in **normalized unit intervals** `[0.0, 1.0]` relative to the page's intrinsic PDF points (`72 points per inch`): $$\text{PDF}_x = x_{\text{norm}} \times \text{PageWidth}_{\text{points}}$$ $$\text{PDF}_y = (1.0 - y_{\text{norm}} - h_{\text{norm}}) \times \text{PageHeight}_{\text{points}}$$ Because the coordinate translation is a pure mathematical projection, the resulting stamped vector signature aligns with sub-millimeter precision regardless of whether the document was signed on an iPhone or an ultrawide desktop. --- ## 4. Architectural Comparison: Legacy SaaS vs. Cloudflare Edge | Architectural Layer | Legacy Incumbent Stack | Pumasi Sign Edge Stack | | :--- | :--- | :--- | | **Runtime Environment** | Dedicated Kubernetes clusters with Node/Python/LibreOffice | Cloudflare V8 Worker Isolates (<5ms cold start) | | **PDF Manipulation** | Forked background C++ processes & rasterizers | In-isolate TypeScript vector stamping (`pdf-lib`) | | **State & Storage** | AWS RDS PostgreSQL + S3 Buckets (high egress cost) | Embedded SQLite in Cloudflare Durable Objects + Cloudflare R2 | | **Multi-Tenancy** | Complex organization schemas with gated features | Instant workspace provisioning with customizable branding | | **Operational Cost** | High fixed monthly server & database infrastructure | Fractional token & edge invocation cost ($0 at scale) | --- ## 5. Software as an Unmetered Commons When the infrastructure cost of executing an agreement drops to near zero, the business model must change. Pumasi Sign has no envelope meters, no per-seat paywalls, and no gated features. It is **not yet licensed**: as of **2026-08-31** the repository carries no `LICENSE` file on its default branch — checked with `gh api repos/pumasi-ai/pumasi-sign/contents/LICENSE`, which returns `404`, and neither its `package.json` nor its README declares one. Read the source and run it, but until that file lands nobody here has granted you a licence to it: - Run it locally or self-host on your own Cloudflare account: `git clone https://github.com/pumasi-ai/pumasi-sign && npx wrangler deploy`. - Use the public commons deployment at [**https://sign.pumasi.ai**](https://sign.pumasi.ai) with your own custom branding. Contracts and agreements should record trust between counterparties—not pay a tax to a software tollbooth.

The per-seat tax on hiring hourly workers

2026-08-29T00:00:00Z

Staff shift scheduling is sold per employee per month. That sounds unremarkable until you notice what it means for the businesses that need it most: a restaurant that hires four people for the summer pays more for scheduling software in July, having changed nothing about how it schedules. The bill is indexed to headcount. The work is not. ## What it costs today **When I Work** publishes $2.50 per user per month for Essentials, $5 for Pro, and $8 for Premium, with API access, webhooks and SAML/SSO gated to the top tier — the SSO tax, applied to a rota tool ([wheniwork.com/pricing](https://wheniwork.com/pricing), checked 2026-08-29). **Deputy** publishes $5 for Lite, $6.50 for Core and $9 for Pro per user per month, plus paid add-ons: HR at $2, Messaging+ at $1.95, Analytics+ at $1.50, all per user per month, over a $30 monthly minimum. The whole structure was rearranged in October 2025 ([deputy.com/pricing](https://www.deputy.com/pricing); [RosterElf's 2026 review](https://www.rosterelf.com/reviews/deputy); [ITQlick on Deputy's hidden costs](https://www.itqlick.com/deputy/pricing)). For a thirty-person restaurant on Deputy Core with HR and Messaging+, that is a little over $310 a month to answer the question *who is working Thursday*. | Platform | Base Pricing (Per User) | Gated Add-ons & Surcharges | Monthly Bill (30 Seats) | Annual Bill | | :--- | :--- | :--- | :--- | :--- | | **When I Work** | $2.50 – $8.00 / user / mo | SAML/SSO & API gated to Premium | $75.00 – $240.00 / mo | $900 – $2,880 / yr | | **Deputy** | $5.00 – $9.00 / user / mo | +$2.00 HR, +$1.95 Messaging, +$1.50 Analytics | $313.50 / mo | $3,762 / yr | | **Homebase** | $24.95 – $99.95 / location | +$3.00/user over limit + Payroll fees | $99.95 – $199.95 / mo | $1,200 – $2,400 / yr | | **Pumasi Commons** | **$0.00 (Unmetered)** | **Zero per-seat tax · Free Forever · Apache-2.0** | **$0.00 / mo** | **$0.00 / yr** | ## The public page and the trial disagree Here is the part worth the trial fee. Pumasi's evidence for a candidate is not allowed to rest on an incumbent's marketing pages. A candidate whose incumbent has not been toured **signed in** is marked *provisional* and cannot hold a settled score. On 2026-08-29 the steward provisioned a fourteen-day When I Work trial and toured it: sixty-five screenshots, signup through to admin. The in-app plan picker did not match the public pricing page. Inside the trial there are **two** plans, not three — $2.50 per user per month for a single location and $5.00 for multiple locations — each bundling scheduling, time tracking and attendance, and messaging together. And one-click **auto-scheduling is included at $2.50**, against the reasonable assumption, formed from the outside, that the clever feature would be the thing behind the paywall. It is not. The paywall is **location count**. That correction matters more than it looks. It moves the incumbent's real moat from "we have the good algorithm" to "we charge you for growing," which is a much weaker position to defend and a much clearer thing to build against. It also did not move the candidate's score by a single point — the demand and the resentment were already scored correctly. The tour bought *accuracy*, not a different answer. ## The resentment is the pricing model itself The complaint volume is not about features. It is about the meter. There is an entire content genre of *"alternatives that don't charge per employee"* ([one example](https://www.deelo.ai/blog/deputy-alternatives-small-business-2026)), which is what a market looks like when the pricing model, rather than the product, is what people want to escape. Meanwhile the open-source field is dead or mislabelled. Staffjoy, the one venture-backed open-source attempt, shut down and deprecated its repository in September 2019 ([github.com/Staffjoy/v2](https://github.com/Staffjoy/v2)). The "best open-source scheduling" roundups are reduced to listing TimeTrex — an open-core payroll suite, not a rota tool — and OptaPlanner, a constraint solver, which is a library and not a product ([SelectHub](https://www.selecthub.com/employee-scheduling/open-source-employee-scheduling-software/), [People Managing People](https://peoplemanagingpeople.com/tools/best-open-source-employee-scheduling-software/)). So: proven demand, a public per-seat price, documented resentment aimed squarely at the meter, and no living open-source alternative. That is close to the definition of what this commons exists to copy, and it is why staff shift scheduling currently sits at the top of the [public backlog](https://github.com/pumasi-ai/pumasi-product-hunt) with a settled score of 45 out of 50. ## What the copy would have to get right The tour was clear about where the product actually lives, and it is not the scheduling algorithm. The heartbeat is **draft → Publish & Notify**. The scheduler is a week grid by person; edits accumulate as drafts with a change count; publishing notifies every affected employee, and republishing notifies them again. Everything else in the product orbits that moment. A first version without integrations can still hit it: publish a read-only page plus an ICS feed, and treat *"what changed since the last publish"* as a first-class object rather than a diff computed at send time. Underneath, approvals turn out to be one state machine reused three times — shift requests, time-off requests, and open-shift claims. Pure, cheap, and central to daily use. Attendance and timesheets are a genuinely separate second product bundled into the price, and a first version should say so and leave them out. None of that is hard. It is just nobody's job, which is the whole problem this commons exists to fix. --- *Figures checked 2026-08-29 against the linked sources and one signed-in trial. Prices move; the date is part of the claim. Pumasi studies incumbent behaviour, never expression — no incompatibly licensed code is read while a competing implementation is being written.*

The six scheduling traps that catch AI coders (and how multi-model review caught them)

2026-08-29T00:00:00Z

Ask any modern LLM to write a meeting scheduler, and it will give you a clean, plausible-looking TypeScript function in five seconds. It will define `getAvailableSlots()`, iterate over start and end hours, and return an array of ISO 8601 strings. And in production, that function will quietly double-book your calendar, drop an hour during daylight saving time, or lock out attendees across international timezones. When we built [`@pumasi/booking-core`](https://github.com/pumasi-ai/pumasi-booking/tree/main/core), we didn't rely on a single model's confidence. We used **heterogeneous cross-family review** (Claude, Gemini, and Grok reviewing each other's work) backed by frozen acceptance suites. Here are the six subtle traps that were caught and fixed along the way. --- ## 1. The Spring-Forward Gap: Two Hours, Not Three When a timezone springs forward (e.g. 02:00 skips directly to 03:00): * A naive loop generating slots between 01:00 and 04:00 will generate three 60-minute slots: `01:00-02:00`, `02:00-03:00`, and `03:00-04:00`. * But in local wall-clock time, **02:00 to 03:00 does not exist.** The interval between 01:00 and 04:00 is only **two absolute hours long**. Generating a slot during the missing hour means offering a time that physically cannot occur. In `@pumasi/booking-core`, invalid local times are skipped loudly with explicit diagnostics rather than silently shifted to the next valid hour. --- ## 2. The Fall-Back Ambiguity: Both Occurrences Must Be Bookable In autumn, wall clocks repeat an hour (e.g. 01:00 to 02:00 happens twice). * A 3-hour window spanning the repeated hour contains **four elapsed hours**, not three. * Naive code often deduplicates slots based on string matching (e.g., matching `"01:00"`), which silently deletes the second valid hour from availability. The engine represents time in unambiguous UTC instants paired with the owner's IANA timezone, ensuring both occurrences in the transition window can be booked independently. --- ## 3. Daily Booking Caps Must Count on the Owner's Local Date If an organizer sets a limit of *"maximum 3 bookings per day"*: * Suppose a booker in Tokyo (UTC+9) schedules a meeting with an organizer in San Francisco (UTC-7). * In Tokyo, the meeting is on Tuesday morning. In San Francisco, it is still Monday afternoon. Which day's cap does the meeting consume? **It must count toward the owner's local date.** If the cap evaluates in UTC or the requester's timezone, an organizer can receive 6 meetings on a Monday because the requests straddled midnight in other parts of the world. --- ## 4. The Cancellation-Replay Trap During early specification review, an adversary model identified three clauses that were jointly impossible to satisfy: 1. *Replaying an idempotency key returns the original booking result.* 2. *A user can cancel a booking, releasing the slot back to the public pool.* 3. *A third party can subsequently book the released interval.* If Party B books the released slot, and Party A then resends their original booking request with their original idempotency key, what happens? * If the server returns the original success result, it falsely claims Party A holds a slot that Party B now occupies. * If the server rejects the replay, it violates idempotency. The resolution: idempotency keys bind strictly to an active, non-canceled booking lifecycle. Replaying an idempotency key for a cancelled or superseded reservation returns a distinct `RESERVATION_SUPERSEDED` state, preventing ghost confirmation states. --- ## 5. Vacuous Acceptance Tests (Tests That Cannot Fail) During review under [`lessons/L-006`](https://github.com/pumasi-ai/pumasi/blob/main/lessons/L-006-tests-that-cannot-fail.md), we discovered an acceptance test designed to check concurrency conflicts. The test spawned two parallel booking requests and asserted: ```typescript if (responseA.status === 200 && responseB.status === 200) { assert.fail("Both bookings succeeded concurrently"); } ``` If the test environment ran sequentially (one request completed before the second began), `responseB` failed normally with a standard slot conflict, the `if` condition evaluated to `false`, and the test passed — **without ever actually asserting that the database exclusion constraint fired.** The fix: acceptance tests must assert both the positive assertion on winner *and* the specific error code (`CONCURRENCY_CONFLICT` / `EXCLUSION_VIOLATION`) on the loser, ensuring no test can pass vacuously. --- ## 6. Double-Booking Prevention Belongs Inside the Database Many SaaS booking engines attempt to prevent double-booking in application code: ```typescript // DANGEROUS: Classic Check-Then-Act Race Condition const isBusy = await db.checkOverlap(timeSlot); if (!isBusy) { await db.insertBooking(timeSlot); } ``` Under high concurrency, two simultaneous requests will both pass `checkOverlap()` before either executes `insertBooking()`. In Pumasi Booking, concurrency guarantees are enforced **inside the database engine**: * **PostgreSQL Build**: Enforced with a `btree_gist` temporal exclusion constraint (`EXCLUDE USING gist (organizer_id WITH =, booked_range WITH &&)`). * **Cloudflare Workers / SQLite Build**: Enforced with atomic `BEFORE INSERT` and `BEFORE UPDATE` SQL triggers raising `ABORT`. Application code can crash, restart, or scale across ten distributed instances; the database write lock guarantees that two overlapping bookings can never commit simultaneously. --- ## Why Multi-Model Review Matters Every single one of these six traps was caught not by proofreading, but by having **competing LLM architectures attack each other's designs** before implementation. When an AI writes code, it is confident even when it is wrong. Putting heterogeneous reviewers and frozen acceptance tests between the prompt and the `main` branch is how you turn generative AI into reliable open-source infrastructure.

Why we show the seams: building in the open before the product is stable

2026-08-29T00:00:00Z

Most software projects wait until they feel polished before opening their doors. They scrub their issue trackers, draft aspirational marketing copy, and quietly paper over edge cases. When something breaks, it is treated as a surprise. We are taking the opposite approach with **Pumasi Booking**. The product is in **seed stage**, under active construction, and not yet stable. If you deploy it expecting a mature, five-year-old enterprise SaaS replacement today, you will find edges that are still being sanded down. Instead of hiding those seams, we put them at the very top of the page. Here is why. > **Update, 2026-08-31.** The stage sentence above was true the day this was > published and is no longer. Pumasi Booking's > [`STAGE.md`](https://github.com/pumasi-ai/pumasi-booking/blob/main/roadmap/STAGE.md) > has said **`beta`** since 2026-08-29 — strangers can rely on it, the known > gaps are listed, data survives — and it is re-justified at each release > evaluation rather than left to drift. The argument below is unchanged; only > the label moved. The current stage, and the limitations that come with it, > are on the [product page](/products/pumasi-booking/), which is the surface > that tracks the roadmap. This post is left as it was written rather than > quietly edited, because a dated argument that gets retconned is worth less > than one that carries its own correction. --- ## 1. The limitation comes before the feature list Every product page in the Pumasi catalog follows a strict rule: **the first thing you read is what the software cannot do yet.** For Pumasi Booking, the top of the page does not boast about AI-native workflows or frictionless booking. It states plainly: > *Limitation: no lawyer has reviewed its privacy pack, and no standard contractual clauses cover its US transfer position — the legal pages it serves say so on their face.* If you are evaluating software for your organization, your first question is not *"what is the happy path?"* — it is *"will this break my compliance, drop a customer meeting, or corrupt data under concurrency?"* An honest project answers that question before you spend twenty minutes setting it up. --- ## 2. A debt register is better than a marketing promise In [`governance/DEBT.md`](https://github.com/pumasi-ai/pumasi/blob/main/governance/DEBT.md), we track every single operational and architectural rule we are running below right now: * **D-105**: The lawful basis is written in `service/src/legal.ts`, but an international transfer mechanism and a formal review by legal counsel remain open. * **D-108**: Telemetry egress is currently disabled in code (`PUMASI_REPORTING` is read into config and read by nothing), meaning our multi-environment verification matrix is currently one machine wide. * **D-104**: Multi-model reviewer availability fluctuates, and we report the exact live count rather than asserting that three families are always active. A project that runs below its own rules quietly is worse than one with no rules at all, because it sells a guarantee it is not providing. Publishing debt is how we keep ourselves honest while the software matures. --- ## 3. The core engine is pure, testable, and separable While the full service layer (HTTP, auth, sessions, SQLite/PostgreSQL connectors) is being hardened, the computational core underneath it — [`@pumasi/booking-core`](https://github.com/pumasi-ai/pumasi-booking/tree/main/core) — is already rock solid. Availability calculation and slot allocation is implemented as a **pure mathematical function**: * **No clock**: Time is an explicit parameter, not an ambient system call. * **No I/O**: No network requests or database queries happen inside slot computation. * **No mutable state**: Same inputs yield byte-identical outputs across any runtime. Because of this boundary, you don't have to trust our full web stack to use the engine. You can extract the engine alone with full Git history in one command: ```bash git subtree split --prefix=core -b engine-only ``` You get a pure TypeScript availability calculator with frozen acceptance tests covering spring-forward DST transitions, cross-timezone boundaries, and buffer interactions — free to embed into your own backend. --- ## 4. How to help during the seed phase If you want to try Pumasi Booking today: 1. **Run the pure test suite**: Clone the repo and run `npm test`. Check whether the acceptance cases in `core/spec/acceptance/cases.json` hold for your timezone and locale. 2. **Test local self-hosting**: Spin up `docker compose up` and test connecting your Google or Microsoft calendar in testing mode. 3. **File structural bugs**: If you find an edge case where a timezone transition or booking buffer produces an invalid slot, file an issue. In our process, a bug report isn't a support ticket — it becomes a permanent, numbered acceptance case in our test matrix. We are building a commons meant to last decades. Starting with radical honesty about what is not yet finished is the only foundation that makes "built once, well, to serve everyone forever" credible.