About the Project
When I visited my father's embroidery and silk screening business in David, Panama in 2007, I found controlled chaos. Orders were getting mixed up, inventory was scattered across the shop floor in unmarked boxes, and the staff constantly interrupted my brother to ask where things were or how to set up machines. The business was growing, but without any formal systems in place, that growth was creating more problems than profit.
Over the next five years, I became the company's sole technical resource, building a complete business management suite while working remotely from Boston. I developed 5 Ruby on Rails applications totaling 15,400 lines of code and 441 commits across 42 months, with 2 applications serving in production for 5+ years. I was building all of this while also taking on Rails client projects in the Boston area.
The result: revenue doubled from ~$155K to ~$314K annually (supporting ~$1.55M total over 6 years), turnaround time improved 46% (67 days to 36 days), and transaction capacity increased 40% (148 to 207 orders/month).
The Problem Space
I knew from my work at The Village Bank that database-driven applications could radically improve how a business operates. But S.B.C. presented unique challenges: no IT budget, no computers beyond a single shared desktop, no money for commercial software licenses, and I was based over 2,000 miles away in Boston.
The bigger challenge wasn't technical. It was figuring out which problems to solve first in a business where everything felt urgent and nothing was documented, while managing the complexity of distributed development before remote work tools were mature.
If I was going to help, I'd need to solve not just the software problems but the infrastructure, deployment, and operational challenges. I'd essentially be building a technology department from scratch for a company that had never had one.
Domain Immersion
Before building anything, I needed to understand how the business actually worked. During my trips to Panama, I spent significant time working directly in the inventory room. I did inventory counts, organized products, observed workflows, and experienced firsthand the problems the staff faced daily. I was living the workflows I'd be automating.
The inventory room became my classroom. Over 5,000 t-shirts were crammed into cardboard boxes with no organization system, stacked haphazardly around the room. When someone needed a specific size and color, they'd spend 15 minutes digging through boxes, often coming up empty even when the shirt was actually in stock. I spent weeks physically sorting and organizing inventory alongside the staff, learning the 6-dimensional categorization they actually used (Type, Color, Size, Brand, Style, Gender) rather than imposing theoretical systems.
I also studied the paper artifacts the business ran on. Order forms captured customer information, logo placement, and thread color specifications.
These forms revealed what information workers actually needed and how they thought about orders, shaping what the digital systems needed to capture.
Beyond the production floor, I essentially worked a second job managing IT operations and providing hands-on business support: hardware procurement (sourcing computer parts in Panama and upgrading donated equipment), server administration (Ubuntu Linux, networking, backups), and workstation support. This operational work was critical to understanding what the software needed to do. You can't build effective inventory management software without actually doing inventory. You can't design good workflows without experiencing the physical constraints of a busy production floor.
Building the Solution
Computerizing the Business (2007-2008)
I started by creating an IT foundation from donated equipment. I found an organization willing to donate old laptops, sourced replacement parts and a server in the US, and brought everything to Panama. I upgraded the laptops and installed Ubuntu Linux. These became the staff workstations. I set up the server, configured networking, and got everyone connected. None of this was fancy. It was all free or low-cost, off-the-shelf software: Ubuntu for the server, Google Workspace for email and documents, Dropbox for file sharing. Whatever got the job done. But it gave me a working infrastructure for under $5,000 and brought a paper-based business into the digital age.
Inventario: Inventory Management (2008-2011)
My first major application started with a contractor in late 2007. While he built version 1, I worked with the business to create a flexible grid storage system that allowed workers to place inventory wherever it was convenient rather than requiring rigid bin assignments. When the contractor quit in March 2008, I took over completely. By October 2008, I'd rewritten the entire system from scratch as Inventario 2.0, which became the largest component of the suite at 12,000 lines of code.
But even my rewrite was too rigid. Workers struggled to locate and restock inventory efficiently. So I kept watching. I observed how they used the application and where they were getting stuck. That second round of observation led to the features that made the system actually work: fuzzy search that understood "dark blue" rather than hex codes, a custom color picker for visual selection, and the separation of reinventory from order processing.
Order fulfillment time dropped from 15 minutes to under 5. The system worked because it matched how people actually thought about inventory, not how a database schema said they should.
Diseños: Design File Management (2008-2011)
The second major bottleneck was setting up embroidery machines. Workers needed to track down design files and print configuration instructions, a process that took 20+ minutes and required constantly interrupting my brother, the production manager and lead designer. Every interruption meant designs stalled and production slowed. He was spending hours each day being a human filing cabinet instead of running the business.
I planned the interface on whiteboards before writing code, mapping out how workers would search for designs and view thread color breakdowns.
The wireframes show AJAX search patterns and the data relationships between designs, colors, and thread brands.
What the UI looked like in production.
Diseños became the most actively developed application in the suite with 206 commits over three years. It managed industry-specific embroidery file formats (DST, PES), handled thread color assignments, provided full-text search, and integrated a JavaScript colorpicker widget for visual color selection. Setup time dropped from 20+ minutes to under 1 minute, and workers could find everything themselves.
June 2009 was the most intense development period: 87 commits in a single month implementing Cucumber BDD testing, complete Spanish/English internationalization (215 lines of translations), timeline events for audit trails, email sharing functionality, and the colorpicker integration.
Remote Development and Deployment (2008-2012)
The technical challenge wasn't just writing code. It was deploying and maintaining production systems in Panama while living in Boston. I established a remote access system using Hamachi VPN to create secure tunnels to the Panama servers, combined with Capistrano for automated deployment. This let me push code changes, monitor systems with NewRelic, handle exceptions remotely, and maintain the infrastructure without being physically present.
This was 2008-2011, before remote work tools matured. I was solving distributed deployment problems that are now standard DevOps practice but were cutting-edge then. The development pattern became: build features in Boston, deploy remotely to Panama, travel for extended on-site periods to observe real usage (including one 4-month trip from December 2009 to March 2010), refactor based on reality, then return to Boston for the next iteration.
The Complete Suite
The production system consisted primarily of Inventario and Diseños, supported by:
- Coto Solutions (494 LOC): Shared plugin providing reusable components across all applications
- SBC Portal: Sinatra-based launcher that tied everything together with intelligent app discovery
I also built Ordenes (585 LOC), an order tracking system, during a January-February 2011 trip to Panama. [See: Ordenes wireframe mockup] While I developed it to beta stage with testing, it was never deployed to production. I moved away from active work with S.B.C. before completing the rollout.
The production suite (Inventario + Diseños + infrastructure) totaled approximately 14,800 lines of code. I adopted technologies before they became Rails standards: HAML and SASS in 2008 (Rails 3.1 wouldn't default to them until 2011) and Cucumber BDD in 2009. Each application was small, independent, and deployed separately, communicating through the database and shared infrastructure.
Long-term Impact
The production system (Inventario and Diseños) cost S.B.C. less than $5,000 to build and deploy, and transformed how the company operated. Revenue doubled from ~$155K (paper-based baseline in 2007-2008) to ~$314K (new digital ceiling in 2010-2012), supporting ~$1.55M in total revenue over six years. Turnaround time improved 46%, from 67 days average to 36 days, and transaction capacity increased 40% (from 148 to 207 orders per month).
The design database created a compounding effect: the system became a cache. Repeat customers could be served from the existing library without designer involvement, decoupling revenue growth from design labor. Workers gained both confidence and autonomy. They knew what to do and where to find what they needed without constant supervision.
The system served the business in production for over five years with three major Rails upgrades (2.2 to 2.3 to 3.1) and continued maintenance. In 2025, I resurrected the applications using Claude Code, migrating them from Rails 2.x to Rails 4.2 as both a preservation effort and a working demonstration of the approach.
For me, this project reinforced lessons that shaped every system I've built since: the best technology solutions come from deep understanding of actual workflows, not theoretical requirements. Observation beats analysis. Working in the business, actually doing the inventory, experiencing the frustrations, taught me more than any requirements document could have. And you can accomplish sophisticated engineering with modest resources if you're resourceful and willing to handle everything from hardware procurement to writing code to organizing t-shirts.
Technical Details: The suite included Inventario (12,000 LOC), Diseños (2,000 LOC with 206 commits), and supporting infrastructure including Coto Solutions plugin (494 LOC) and SBC Portal launcher. Ordenes (585 LOC) was built to beta stage but not deployed to production. Development spanned October 2008 through April 2011 and beyond, with 441 commits across 42 months. The production system included complete Spanish localization, production monitoring (NewRelic), exception notification, multi-layer caching, full-text search (Thinking Sphinx), automated deployment (Capistrano), and remote management via VPN (Hamachi). Infrastructure ran on Ubuntu Linux with donated/upgraded hardware. Over six years (2007-2012), the system supported ~$1.55M in total revenue, an ROI exceeding 1,000% on the initial $5,000 investment.