Mashdun
AI GrowthWorkCapabilitiesIntegrationsProcessLabsMarketplaceBlogAbout
Get in Touch
Mashdun

Full-stack web developer, AI engineer & growth marketer. Building production-grade apps and intelligent solutions.

Navigation

  • Portfolio
  • Capabilities
  • Process
  • Labs
  • About

Resources

  • Blog / Notes
  • Marketplace
  • Contact
  • RSS Feed

Legal

  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • Do Not Sell or Share
  • Delete my data

© 2026 Mashdun. All rights reserved.

Built with Next.js, Tailwind CSS & Prisma

    Back to Work
    Web Development
    SaaS / Compliance

    SignSealer — Digital Agreements You Can Prove

    Client: SignSealer (Founder)

    Electronic signatures, waivers and tamper-evident records built on an evidence model that treats the signature as the least interesting row in the store — with a v1 API, a retrying SDK, and executed agreements sealed as PAdES-T PDFs any reader can verify.

    Next.js
    TypeScript
    PostgreSQL
    SaaS
    Supabase
    Live Site
    SignSealer desktop screenshot
    SignSealer mobile screenshot

    Context & Objective

    E-signature tools prove that somebody clicked. Businesses that run on waivers and agreements — rentals, recreation, hospitality — need to prove what was agreed, by whom, and that it has not changed since, to somebody who does not have access to their system.

    Outcome

    A signing engine whose rules live in Postgres rather than in application code, asserted by 280+ assertions across nine SQL suites plus end-to-end API and PDF suites run against a database rebuilt from migrations. One engine serves three consumers: the SaaS, DeckPOS waivers, and the Mashdun signing module.

    Key Highlights

    • PAdES-T sealed PDFs — agreement and certificate in one file, timestamped over the signature so the authority never sees the contract
    • Tamper provable two ways: to anyone who can query the database, and to a stranger's PDF reader with no access at all
    • Reservations as a first-class primitive — subject facts drive requirement rules, and a packet emits a ready event when the last required signature lands
    • Minority judged on the arrival date, never the signing date; a blank date of birth is refused rather than read as an adult
    • Idempotent by construction — a replayed key returns the stored response, a reused key with a different body is refused
    • Messaging that honors suppression and quiet hours in the guest's own timezone, with the transactional carve-out named on the row so it can be audited
    • Operator access as an expiring membership: every look leaves a row, and no operator can read what a customer's counterparties signed
    • Billing on one unit — a completed agreement — keyed to the event that caused it, so a charge can always be shown its own evidence

    Tech Highlights

    • PostgreSQL as the rules engine — capabilities, per-tenant audit chains and refusals enforced in SQL, not application code
    • TypeScript v1 API with bearer keys as first-class members, scopes, and signed webhooks
    • Dependency-free SDK over fetch that retries under an idempotency key and surfaces the API's own error text
    • Self-issued PAdES-T sealing verified against openssl as an outside checker, AATL-ready with no code change above the sealer
    • Per-tenant branding — logo, colors, sender name and a custom domain that resolves only once proven

    Published

    September 1, 2026

    Interested in something similar?

    Let's discuss your project.

    Get in Touch