Example package
Daily report script
Reports from two or three systems downloaded, merged and emailed every morning.
You get
- Script that pulls each source
- Merged report in Excel or Sheets
- Scheduled run and email delivery
- Failure alert and a run log
Sound familiar?
What we hear from businesses before a project like this starts.
- We have a script that works on one person's laptop and nowhere else.
- Someone downloads three reports, merges them and emails the result, every morning.
- Our Python tool needs to run on a server when an order comes in, not on a desktop.
- We need a small tool for the team, but not a whole application.
- Windows warns people every time they open the tool we built.
What buyers usually need
The requests that come up most often for this kind of work, and what each one takes to work properly.
01
A script moved to the cloud
A script that runs on someone's laptop packaged and moved to a small cloud service your website or system can call.
02
Files processed in bulk
Folders of CSV, Excel, PDF or images renamed, converted, merged or checked in one run.
03
Data pulled from an API on a schedule
A job that pulls from a service's API and writes to a sheet, database or file every hour or day.
04
A small tool for the team
A command-line tool, a simple web form or a desktop app that does one task with a few inputs.
05
A Windows app that installs cleanly
A packaged installer, signed with a code-signing certificate so Windows SmartScreen stops warning users.
06
An existing script repaired or extended
Someone else's script read, repaired, given error handling and documented.
Tools that come up most: Python, pandas, requests, FastAPI, Flask, Google Cloud Run, AWS Lambda, cron, Docker, PyInstaller, Windows code signing.
What you get
Concrete pieces, each one something you can open and check when it's done.
Scheduled jobs
Scripts that run on a schedule in the cloud, with logs and a failure alert.
cron, Cloud Run jobs, AWS Lambda, GitHub ActionsAPI integrations
Small services that pull from or push to the APIs your business already uses.
requests, FastAPI, webhooksFile processing
Bulk conversion, renaming, merging and checking of files.
pandas, openpyxl, pypdf, PillowCommand-line and desktop tools
Tools with a few inputs and one clear output, packaged for the people who use them.
Click, Tkinter, PyInstallerWeb endpoints for scripts
A script wrapped as a small private web service your site or system can call.
FastAPI, Cloud Run, DockerTests and docs
Tests for the important parts, and a README a new person can follow.
pytest, READMETypical projects
Example packages to show the shape of the work. These are examples, not past clients; yours gets its own written scope.
Example package
Move a script to the cloud
A working local script turned into a private cloud service that your website calls when needed.
You get
- Script packaged in a container
- Deployed to Cloud Run or similar in your account
- Secured so only your system can call it
- A run book for redeploying
Example package
Bulk file tool
A tool that processes a folder of files the way your team does by hand.
You get
- Command-line or simple desktop tool
- A summary of what was processed and what failed
- Tested on your sample files
- Instructions for the team
Example package
Signed Windows installer
Your Python tool packaged as a Windows installer and signed, so it installs without warnings.
You get
- Packaged executable and installer
- Code signing with your certificate
- A clean-machine install test
- Steps to sign the next release yourself
Example projects
Shelf-audit computer vision for a beverage distributor
A beverage distributor's field reps were counting cooler facings by hand at 200+ stores. We built a computer-vision pipeline that works from a single phone photo. It detects every bottle, identifies the brand, counts facings per shelf, finds empty slots, and compares the shelf to the store's planogram. Reps get the result in seconds. The system creates restock orders for short brands, flags misplaced products, and emails the store manager an audit PDF.
- Object detection and brand classification model trained on the distributor's own photos
- Facing counts, empty-slot detection and planogram comparison
- Review screen for supervisors, with approve-and-correct to keep improving the model
- Restock order creation and audit PDFs
Python, PyTorch, YOLO object detection, OpenCV, FastAPI, PostgreSQL, React, React Native
Job-site photo organizer for a home-renovation contractor (Python)
A renovation contractor's crews were sending thousands of phone photos a week into one shared folder, and the office spent hours sorting them by job. We wrote a Python command-line tool that sorts them automatically. It matches each photo to a job from its GPS location or a job tag in the filename or a QR code in the shot, fixes wrong camera dates, renames everything to a standard pattern and files it by job and day. It skips duplicates and builds a PDF contact sheet per job. Anything it can't place goes to a review folder, and every run can be dry-run first or undone.
- Command-line tool with YAML rules, dry-run mode and one-command undo
- Job matching by GPS radius, filename tags and QR codes
- EXIF date and time-zone correction, duplicate detection by image hash
- Standard renaming and folder structure, plus PDF contact sheets per job
Python 3.12, Pillow, piexif, pyzbar (QR), ReportLab, Typer, Rich, PyInstaller
Sample build
A working example we built to show this kind of work. It is a demonstration, not a client project.
Sample build
Bulk file renamer with dry run, undo and report
Python CLI that renames a messy folder of photos and documents to a consistent date_slug_sequence pattern, dating photos from EXIF or modified time. Previews unless --apply is passed, prevents name collisions, writes an undo log and an HTML report.
Python 3.12, Pillow, HTML report
About the screenshots: The HTML report and dry-run output from a run on a sample folder.
How we approach it
The habits that keep this kind of project from going wrong.
1
Reproduce the manual process first
We walk through the job as it is done today, with real files, before writing the script.
2
Fail loudly
Scripts check their inputs and outputs and alert someone when something is wrong, rather than producing a half-right file.
3
Run where it should run
Scripts are deployed to a server or cloud account in your name, not left on a laptop.
4
Readable code
Plain, commented Python with tests, so another developer can pick it up.
How we work
You know what you're getting before work begins, and you see it working at every milestone.
You describe it
Tell us what you need in your own words, and which tools you already use. A few lines is plenty to start.
A written scope
We reply with a short written scope: what gets built, what is out of scope, which accounts we need, and how we'll both know it works. You know what you're getting before work begins.
Milestones you review
The work is split into milestones. At each one you see it working in your own account and sign it off before we go on.
Handover and a 30-day fix window
You get the working system, its documentation and a walkthrough. If anything we built breaks in the next 30 days, we fix it at no charge.
What shapes the scope
- How many systems or file types are involved
- Where it has to run
- Whether a user interface is needed
- Packaging, signing and installer requirements
Always included
- A written scope before work starts
- Milestones you review and sign off
- Documentation and a walkthrough at handover
- A 30-day window for fixes, at no charge
Pushbuild has built software for businesses since 2010, for more than 40 clients. Every project is led by a former public-company CTO, from Groton, Massachusetts. See products we've built.
Questions people ask first
Where will the script run?
Wherever suits the job: a cloud account in your name, a server you already have, or your team's computers. Running costs, if any, are in the scope before you agree.
Do I need to know Python to use it?
No. You get a button, a command or a schedule, plus instructions written for the person who will use it.
Who owns the code?
You do. It goes into a repository you own.
Who buys the code-signing certificate?
You do, in your company's name, because the certificate identifies the publisher. We help with the steps and do the signing setup.
How long does it take?
Most scripts take a few days to two weeks from the signed scope.
What happens after handover?
For 30 days we fix anything we built that does not work as the scope describes, at no charge. After that, any further work is agreed in writing before we touch it.
Tell us what you need built.
Email a few lines about what you want and which tools you use, or call. We reply with questions or a written scope.
hello@pushbuild.com