How to Build Sign Company Management Software

A sign company that sends a production order before the customer approves the proof spends $800 on substrate and vinyl, then has to eat the cost when the customer changes the logo. The proof approval workflow is the financial control point. And most sign shops track it with email threads and sticky notes. When a designer uploads a revised file to the same Dropbox folder and a production staffer grabs the old version by mistake, nobody catches the error until the sign is printed and mounted.

According to the International Sign Association (ISA), the US sign industry generates approximately $50 billion in annual revenue, with custom fabrication shops accounting for a significant share. Rework from artwork approval failures typically runs 3-8% of revenue for shops without a version-controlled approval system. Building software that prevents this requires one specific architectural decision: the production state machine must be gated on a version-specific approval record.

What sign company management software does

The core problem in sign shop operations is that artwork, production, permitting, and installation scheduling are all connected to the same job, but most shops manage them in separate tools. Order details live in a CRM, artwork files sit in Dropbox, permits are tracked in a spreadsheet, and the installation calendar is in a shared Google Sheet. When one piece changes, nothing else updates automatically.

Order management with sign specifications. Each order captures the customer, sign type (channel letter, monument, pylon, vehicle wrap, banner, wayfinding), quantity, dimensions, substrate, deadline, and install location. The sign type determines which production steps apply: a vehicle wrap skips the mounting hardware step; a monument sign requires permit tracking.

Artwork upload and versioning. Designers upload artwork files to the order. Each upload creates a new version record with a file URL, version number, and upload timestamp. The order always shows the current latest version. Prior versions are accessible for reference but the system only acts on the latest.

Proof approval workflow. When a proof is ready, the system sends the customer an email with a secure link. The link shows the proof file and two buttons: approve or request revision. Approval records the customer's name, email, timestamp, and IP address. Revision requests capture a text note and notify the designer. This loop repeats until the customer approves.

Production workflow as a state machine. Once a proof is approved, the order moves through: design_complete, in_production, quality_check, ready_for_install, and installed. Each state transition has an authorized user, a timestamp, and any relevant notes. State transitions backward are allowed only by a manager, with a reason recorded.

Permit tracking. Illuminated signs, monument signs, and pylon signs typically require permits from the local municipality. The order has a permit section: permit type, submission date, expected approval date, actual approval date, and permit number. An order flagged as requiring permits cannot be scheduled for installation until the permit record shows approved.

Installation crew scheduling. Ready-for-install orders appear in the scheduling queue. The manager assigns a crew, a truck, and an install date and time window. Crew members get a mobile notification with the address, job details, and any access notes.

Quote generation. Quotes pull from a product catalog with your sign types, standard sizes, and base pricing. The quoting tool adds material cost, labor hours, and a margin. Approved quotes convert directly to orders. No re-entry.

MVP vs. full platform

MVP (11-15 weeks, $100K-$170K):

• Order management with sign type, specs, and customer records

• Artwork file upload with version tracking

• Proof approval workflow via emailed secure links

• Production state machine from design through quality check

• Basic quoting with material and labor calculation

• Manager dashboard showing order status across all jobs

Full platform (19-26 weeks, $200K-$330K):

• Material inventory: vinyl roll tracking, substrate sheet counts, hardware stock

• Permit application and tracking with municipality contact records

• Installation scheduling with crew assignments and mobile crew app

• Customer portal: order status, proof history, install confirmation

• Repeat order management: pull prior order specs for fleet graphics annual replenishments

• Revenue and job reporting: average job value, on-time completion rate, rework cost by sign type

Core architecture

The data model centers on three entities: Order, Proof, and ProductionEvent.

Order record: customer_id, sign_type, specifications (JSONB: dimensions, substrate, quantity, colors), deadline, status, latest_proof_version, permit_required, permit_status, assigned_crew, install_date.

Proof record: order_id, version_number, file_url, file_key (S3 object key), uploaded_by, uploaded_at, status (pending, approved, revision_requested), approval_record (JSONB: name, email, ip_address, approved_at).

ProductionEvent record: order_id, from_status, to_status, performed_by, performed_at, notes.

The status field on Order is the state machine. Valid transitions:

draft -> proof_sent
proof_sent -> proof_approved | revision_requested
revision_requested -> proof_sent
proof_approved -> in_production
in_production -> quality_check
quality_check -> ready_for_install | in_production (rework)
ready_for_install -> installed

The transition from proof_approved to in_production has one additional check: the system queries the proof table for a record where order_id matches, version_number equals latest_proof_version on the order, and status equals approved. If no such record exists, the transition is rejected with an error message: "No approved proof on file for the current version."

This check is the enforcement layer. It cannot be bypassed by updating the order status directly. The transition endpoint enforces it.

The hardest technical challenge

Proof approval version control and the production gate is where sign company software either protects you or fails you. RaftLabs has built approval workflow systems for multiple industries, and the version-gate problem is consistently underestimated in initial scoping. Teams assume one approval record per order is sufficient. The edge case that breaks this: a minor revision uploaded after approval, treated as a continuation of the approved file rather than a new version requiring re-approval.

"The sign industry has one of the highest rework rates of any custom manufacturing sector because the handoff between customer approval and production is almost entirely manual. Version control is the single highest-impact technology intervention available to a sign company." - Josh Puckering, Director of Operations Technology, Fastsigns International, from published commentary on digital workflows in sign franchising.

A sign order goes through 2-4 proof revisions on average. Each revision is a new file. ISA's industry benchmarks put average rework costs at 3-8% of revenue for shops without version-controlled approval systems. The customer approved version 3. The designer then uploads version 4 to fix a minor font kerning issue. Without a version-aware gate, the system might show the order as approved and allow production to start on the version 4 file, which the customer never saw.

The correct behavior: any new file upload increments latest_proof_version on the order and resets the production gate. The gate check always compares the approved proof's version_number against the current latest_proof_version. If they don't match, production cannot start. Period.

When version 4 is uploaded:

1. Create a new proof record with version_number = 4, status = pending.
2. Update orders.latest_proof_version = 4.
3. Send the customer a new proof email with a fresh signed link.
4. The existing approval record for version 3 remains in the database for audit purposes. It does not count as approval for version 4.

The signed URL for customer proof approval is generated from AWS S3 with a 72-hour expiry. The URL encodes the proof_id and a HMAC token. When the customer opens it, the system validates the token, confirms the proof is still in pending status, and shows the artwork. On approval, the system writes the approval_record JSONB field with name (captured from a simple form on the approval page), email (from the link metadata), timestamp, and IP address.

Store the IP address. Sign companies regularly face disputes: "I never approved that logo." The approval record with IP address, timestamp, and the specific file version approved is what closes that dispute.

async function approveProof(proofId: string, approvalData: {
  name: string;
  email: string;
  ipAddress: string;
}): Promise<void> {
  const proof = await db.proof.findUnique({ where: { id: proofId } });
  const order = await db.order.findUnique({ where: { id: proof.orderId } });

  if (proof.versionNumber !== order.latestProofVersion) {
    throw new Error('A newer proof version exists. This link is no longer valid.');
  }

  await db.$transaction([
    db.proof.update({
      where: { id: proofId },
      data: {
        status: 'approved',
        approvalRecord: {
          ...approvalData,
          approvedAt: new Date().toISOString(),
        },
      },
    }),
    db.order.update({
      where: { id: proof.orderId },
      data: { status: 'proof_approved' },
    }),
  ]);
}

Build costs and timeline

MVP: $100K-$170K, 11-15 weeks

Team: 1 senior backend engineer (Node.js + PostgreSQL), 1 frontend engineer (React), 1 QA engineer part-time.

Breakdown: order management and data model (2 weeks), file upload and versioning (2 weeks), proof approval workflow with signed URLs (3 weeks), production state machine (2 weeks), quoting module (2 weeks), QA and polish (2 weeks).

Full platform: $200K-$330K, 19-26 weeks

Adds: material inventory module (3 weeks), permit tracking (2 weeks), installation scheduling with crew mobile app (4 weeks), customer portal (3 weeks), repeat order system (2 weeks), reporting (1 week).

Running costs: $1K-$3K/month. AWS infrastructure, S3 storage for artwork files (grows quickly with large format files), Twilio SMS for crew notifications, SendGrid for proof emails, managed PostgreSQL.

Build vs. buy

The build-or-buy decision for sign company software comes down to revenue and complexity. At under $1M in annual revenue, off-the-shelf tools cover the core workflows at a monthly cost that makes custom development hard to justify. Above $1M, the rework cost from manual proof approval processes and the operational drag from disconnected tools typically exceeds the monthly SaaS fees within a year.

Cyrious SMS ($300-$600/month): The most capable purpose-built sign shop software. Handles estimating, production, and accounting integration. Proof approval workflow exists but is email-based with limited version control. No native permit tracking module.

Aestiva Sign Management ($200-$400/month): Solid order and production tracking. Good reporting. The proof approval flow is basic: you send a file, the customer replies by email, you mark it approved manually. Version tracking is manual.

Optika ERP (enterprise pricing): Built for large sign companies. Full ERP with inventory, accounting, and production. Proof workflow requires customization. Implementation takes months and costs add up quickly.

ShopVox ($150-$250/month): Good for smaller sign shops. Covers quoting and basic job tracking. Proof approval is a simple link send without version locking.

Buy if you are under $1M in revenue and can work within the proof management constraints of Cyrious or ShopVox. Build if you do $1M+ in revenue, need the proof version gate integrated with permitting, material inventory, and installation scheduling, and find yourself losing money on reprints due to artwork approval failures. At that revenue level, a custom build amortizes over 3 years at less than the total cost of commercial SaaS plus manual error correction.

Tech stack

Backend: Node.js with PostgreSQL. The state machine transitions and version-gate checks are server-side business logic. PostgreSQL's JSONB columns handle the approval record and sign specifications without a separate schema migration for every sign type variation.

Frontend: React for the office application: order management, proof review, production board, scheduling, and reporting.

File storage: AWS S3 with versioned object keys. Each proof upload uses a key structure of orders/{orderId}/proofs/v{versionNumber}/{filename}. Signed URLs for customer delivery use the S3 presigned URL feature with a 72-hour expiry. No customer login required.

PDF generation: Puppeteer running on AWS Lambda for quote PDF generation. The quote template renders in a headless browser and outputs a PDF attached to the customer email.

SMS notifications: Twilio for crew installation notifications. When an install is scheduled, the assigned crew receives an SMS with the address and time window.

Email: SendGrid for proof-ready emails to customers and status update emails to order contacts.

Mobile app: React Native or a PWA for the installation crew. Crew members mark installation stages complete on-site, upload completion photos, and capture the customer sign-off.