Software for a season that runs on spreadsheets, texts, and memory.

It is one system for the whole seasonal cycle: the photo-mockup quote, the install route, the crew day, the takedown, and the storage. The customer record keeps every season, so the design, the photos, the bulb counts, and the storage bin are all in one place when October comes around again.

The first release covers one complete seasonal cycle, from the first mockup to the last bin on the shelf: the customer record, the mockup and quote, the install routes and crew days, the takedown booked at the sale, and the storage. Renewals, mid-season service tickets, and multi-market reporting come after the core cycle works.

You draw the light runs straight onto a photo of the customer's actual house, pick the colours and patterns, and the tool measures the run for you. Customers buy what they can see, and you quote from a real number instead of a guess. The mockup stays attached to the quote and the job, so the crew installs what the customer approved.

Quote the season, not the install. One price should carry the install, the takedown, and the storage, with the takedown date and the storage terms written on the same page. If takedown is missing from the quote, the crew does a second trip in January for free or argues about it later. The deposit is taken at booking, which holds the install date and pays for the lights before the crew goes up the ladder.

Installs and takedowns sit on one calendar, grouped by neighbourhood so the crew drives a tight loop instead of crossing town between jobs. Each crew gets a route-ready sheet for the day: every stop in order, the bulb and bin counts, the access notes, whether payment needs collecting, and the customer's approved mockup so the crew can see what they are building.

The takedown is booked when the job is sold, on the January date you set, so January never starts with a backlog of customer calls. Takedowns run on the same calendar and the same routes as installs, grouped by neighbourhood. The crew that takes the lights down records what came off the house, what is damaged, and which bin it went into, so the record is ready for next October.

Every tub knows whose lights are inside. Each bin carries a label with the customer name, the address, and the item count, and the storage location sits on the job record. The right bins come off the right shelf in October and go back on it in January. A strand that needs replacing is flagged at takedown, not discovered when the crew is already on the roof.

The customer record keeps last year's design: the mockup, the photos, the bulb counts, the spacing, and the placement. Next fall the record brings it all back, and the renewal quote is built from the same design at the new prices. A new crew member can work a house they have never seen, because the record shows exactly what went up last year.

The record must say who owns the lights. When you own them and lease them back each season, the same strands come back year after year and the storage bin is yours to manage. When the customer owns them, you store their lights and return them, and a damaged strand is their replacement to approve. Either way the ownership, the condition, and the storage location sit on the customer record, so the January takedown and the October reinstall agree.

A strand goes dark mid-season and the customer calls. The ticket lands on the same record as the install, with the design, the photos, and the bulb counts attached, so the crew knows what to bring. The visit is routed with the day's other jobs instead of breaking the route. The fix is written back to the record, so the takedown crew sees it in January and next season's design starts from what is actually on the house.

Yes. Crews clock in, update jobs, add photos, and get directions from their phones, and the install packet prints for the truck when you would rather have paper. The office sees the same job the crew sees, so a change made in the field is visible at the desk without a phone call.

Buy a maintained platform when it covers the cycle. Pinecone and JingleCRM are built for Christmas light installers, with photo-mockup quoting, routes, crews, takedown, and storage, and that is the right call for most installers. Build custom when the operation breaks the template: several markets on one record, permanent lighting beside seasonal work, a franchise model with its own rules, or reporting your owners require. Compare the platform fee against the cost of owning the system before you decide.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces do not fit. A Christmas light installation company earns its fee when the work needs coordination across the mockup, the quote, the routes, the crews, the takedown, and the storage: one accountable party, one phase price, and checkpoints against the whole season. If your need is one screen or one fix, hire the freelancer.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how many crews, markets, and customers the system covers, whether permanent lighting, multi-market reporting, and renewals are in scope, what it needs to connect to, and whether data needs moving over. The agreed phase is priced in writing before it starts.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the season agreed at the start: a mockup quote from a house photo, a route the crew can follow, a takedown date on the calendar, and a labelled bin that matches the record. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

We need one person who owns the season, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. AI-built prototypes from Lovable, Replit, Bolt, or v0 can be assessed as starting points. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more.

Ask for the quote to name everyone who will use the system, including your own crews and office team. Every platform has two products: what customers see, and what your people use all day: the mockup, the quote, the routes, the crew day, the takedown, the storage, and a record of who did what. When that second product is quoted as an 'admin panel' on a single line, it becomes the overrun. Our quotes treat your team's screens as their own scope, with their own users. Then the phase names the workflow, what 'done' looks like, the price, and the exclusions, all before paid work starts. You review working software at agreed checkpoints, and when new information changes the scope, you hear the effect on price and timing before anything is approved.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.