Walker & Homes Photography
<h2>One system from booking a property shoot to downloading the finished media</h2><p>Walker & Homes is a real-estate photography business. Its software has to coordinate customers, properties, scheduling, payments, photographer uploads, video processing, floor plans, revisions, and final delivery.</p><p>Through A5 Software, I worked directly with the owners to understand that operation, then built and continue to maintain the application around it. The result is a client-owned platform that replaces a collection of disconnected booking and media-delivery tools.</p><p></p><img src="https://vivujyp67aiffgjd.public.blob.vercel-storage.com/projects/images/content-image-1788909495930-ref65Vl8AYxyg3TRtFhXbrhHwXsxsa.png" alt="Walker and Homes media workspace showing a paid demo booking with property details and media-delivery controls." style="border-radius: 0.75rem;"><p><em>A booking keeps payment, property details, photos, floor plans, video, and delivery controls in one operational workspace.</em></p><h3>At a glance</h3><ul><li><p><strong>Role:</strong> Founder & Software Engineer, A5 Software LLC</p></li><li><p><strong>Team:</strong> Sole application developer working directly with the owners</p></li><li><p><strong>Timeline:</strong> May 2025 to present</p></li><li><p><strong>Status:</strong> In production</p></li><li><p><strong>Focus:</strong> Booking, scheduling, payments, customer access, media processing, delivery, and operations</p></li></ul><h2>The business problem</h2><p>A real-estate agent should be able to book a shoot and receive the finished photos without understanding the systems behind it. For the business, however, one order crosses several boundaries: calendar availability, property access, pricing, payment status, large uploads, video processing, and permission-controlled delivery.</p><p>I could not design those pieces in isolation. A change to scheduling affects photographers. A change to payment status affects whether media can be released. A failed upload can delay a listing. Much of my work was learning the owners' real workflow, finding the exceptions, and turning those rules into software they could operate every day.</p><h2>The hardest engineering problem</h2><p>Final deliveries can contain thousands of photos, videos, floor plans, and other files. The original download path built a ZIP while streaming it through the application server. On a slow customer connection, archive data could accumulate in memory faster than the browser downloaded it. Large or concurrent downloads could put the rest of the application at risk.</p><p>I replaced that path with a bounded multipart pipeline. The application builds the archive directly into S3, using real backpressure and approximately 40 MB of application memory regardless of the final ZIP size. It then verifies payment and ownership before redirecting the customer to a signed download link that expires after 15 minutes.</p><p>S3 handles the long download. The application server remains available for bookings, uploads, and other customers.</p><p></p><img src="https://www.andrewjf.com/projects/case-studies/walker-delivery-pipeline.svg" alt="Media delivery pipeline showing access checks, bounded archive creation in object storage, and a signed customer download." style="border-radius: 0.75rem;"><p><em>Large archives are built directly in object storage and downloaded without passing through the application server.</em></p><h2>What I owned</h2><ul><li><p>Mapped business rules directly with the owners and translated them into product workflows.</p></li><li><p>Built booking, scheduling, pricing, payments, customer access, and administrative tools.</p></li><li><p>Built large-file uploads, video processing, property pages, floor-plan handling, and customer delivery.</p></li><li><p>Added payment and ownership gates so original media is released only to the correct customer after payment.</p></li><li><p>Continue to diagnose production issues and adapt the platform as the business changes.</p></li></ul><h2>Results</h2><ul><li><p>Supports the core workflow of a business serving more than 100 clients.</p></li><li><p>Keeps archive-building memory near 40 MB instead of growing with archive size.</p></li><li><p>Moves bandwidth-heavy customer downloads off the application server.</p></li><li><p>Reuses a cached archive only while it still matches the booking's current files.</p></li><li><p>Brings booking, payment, scheduling, production, and delivery into one client-owned platform.</p></li></ul><h2>The tradeoff</h2><p>Building archives in object storage adds preparation state, cache validation, cleanup, and failure handling. That complexity is justified because a customer's connection speed no longer determines how much memory the application consumes or whether other users can keep working.</p><h2>What I learned</h2><p>The hardest part of client software is rarely the screen the client first asks for. It is understanding how money, permissions, people, and failure cases connect across the whole operation. The best technical decision is the one that makes that operation simpler and safer to run.</p>
