Description
Summary We're a small facilities services company in the US. We pay our contractors by hand every two weeks and want one custom app that runs the whole cycle. We have about 8 contractors: cleaners, a handyman, and project labor. Most are paid hourly. We pay every two weeks, so roughly 8 payments per run and about 16 runs a year. Hours get reported informally by phone and text, and someone assembles the list by hand. Please read this part before proposing. We are deliberately cutting third-party services out rather than integrating with them. We're cancelling our time-tracking, payroll, and QuickBooks subscriptions as part of this project. Don't propose building on top of a payroll platform, a bill-pay service, or QuickBooks. We want to own the whole thing. We want a small private web app that does four things: 1. Time tracking, ours. Contractors clock in and out from their phones through a link we text them. No app store download, no account for them to create, no password. We work across four sites, so a location stamp at clock-in matters. Most of our crew speaks Spanish with limited English, so the contractor-facing screens must be Spanish-first. Simple enough to learn in one conversation. 2. Payment run with approval. Every two weeks the app pulls the hours, applies each person's rate, and builds a payment list. One manager reviews it, fixes anything wrong, and approves. Nothing gets paid without that approval. Payday always lands Friday morning, so submission timing has to work backwards from that. The math must be exact, and one approval must never be able to pay twice. 3. Payment, straight from our own bank. Once approved, the app sends direct deposits by ACH from our business account. We plan to use Mercury, whose API does ACH with idempotency keys and status webhooks at no per-transfer cost. Tell us if you agree with that choice or would push back, and why. Contractor bank details should live with the bank, not in our database. 4. Invoicing our client. We send two invoices a month to one client. The first is a flat monthly retainer, identical every time, and it should send itself with nobody touching it. The second is variable: every hour worked past 8 in a day, every weekend shift, and any quoted project work, priced at our billing rates, which are different from what we pay the workers. The app already has that data from parts 1 and 2, so it should assemble the draft, let our manager read it on his phone with each line traceable to a worker and a date, and send it. Right now those extra hours live in someone's memory until invoice time, and whatever gets forgotten never gets billed. Since we're leaving QuickBooks, this invoicing has to go somewhere. We're planning to use a cheap invoicing service driven entirely by our app through its API, so we keep a real record of what was sent and what's been paid. Zoho Invoice looks like the best fit because its API is included on the free tier. Tell us if you agree, would use something else, or would just generate the invoices in the app itself. One hard requirement either way: our manager approves and sends from inside our app. He does not log into a second website to do it. For our books, the app should export clean records for our accountant. It doesn't need to be accounting software. Not in scope: supplier bills coming in to us, document scanning, bookkeeping and general ledger, and year-end contractor tax forms. In your proposal, tell us how you'd handle the payment side, since that's what we're most careful about. Give us your own estimate of hours and total cost rather than working from a number we set, plus what the monthly running cost would be once it's live. Please price the invoicing piece separately as well as in the total, since we may stage it after the payment side is running. We'd like this working in about 2 to 3 weeks.