Freelance software engineering. New Jersey, NYC metro.
A report rebuilt from scratch every month because neither system will export what the other needs. An overnight process that turns out to be a person arriving early. A dashboard the team has asked for twice. I write the software that ends work like that: custom web applications with real data behind them, and Python automation that runs without being started.
I hold a full-time engineering job, so freelance work happens on evenings and weekends: one or two projects at a time.
Software with a login, a database, and more than one kind of user. This is what you commission when the spreadsheet has run out of room and the off-the-shelf tool will not bend to the way you actually work.
This is for you if two or more people need to work on the same records at the same time, and the current arrangement is one shared file plus an understanding that nobody touches it at once.
Scheduled Python that runs whether or not anyone remembers it. Most of the work is getting two systems to exchange data when neither was built with the other in mind.
This is for you if the process itself is already correct, and the only weak point in it is that it requires a specific human being to be at their desk.
A full-stack reference application covering the original 151 Pokemon. Both halves are mine, and it is live.
The front end is React and TypeScript. The API behind it is Node, Express and MongoDB, with full CRUD over the whole set of 151. I reworked the request pattern so the interface asks the API for fewer things, which is what made it feel responsive rather than merely correct. Two public repositories, both linked below.
A digital attendance system for teachers, built by a team. The API, its documentation and the instructor reports were mine.
The product was a React front end over a Node and Express API on AWS, with RDS for the database and Lambda for compute, built by a team working in Scrum with Jira. Mine was the API, the attendance reports that put participation metrics and trends in front of instructors, and the technical documentation the other developers built against: endpoints, request and response formats, usage examples. I ran user testing and gathered feedback by survey to decide what actually needed changing, and work I hand over is documented for the same reason. The product's domain has since expired. The repository is the record.
A Python job that reads posted shifts out of a workforce scheduling portal and writes them into Google Calendar.
The scheduling system my employer used at the time published shifts on a web page and nowhere else. No export, no calendar feed, no API. Selenium signs in, BeautifulSoup lifts the schedule out of the HTML, and the Google Calendar API writes the events on a fixed schedule. There is no manual step left in it: small piece of software, one recurring chore permanently gone.
I write software full time as an engineer in the NYC metro area. That is the day job and it stays the day job. Outside projects run on my own hours, which is the honest reason I keep the number of them small. My degree is in computer science, from the New Jersey Institute of Technology in Newark, finished in May 2025.
Before the degree finished I spent about three years as an assistant manager at a busy entertainment venue, coordinating a team of over 100 people. That is where automation stopped being coursework: I wrote Python, Flask, Selenium and BeautifulSoup against the managerial and operational tasks I was accountable for. A script inside a working business has to still work on a Monday morning when nobody is watching it. Running a floor that size also means I have briefed and chased a large group of people, so deadlines and status updates are familiar ground.
I also worked as a teaching assistant in an after-school coding program, teaching Python to students aged 12 to 18: running the exercises, then sitting with them while they debugged their own code. If you do not write software yourself, that is the part worth knowing. You should finish our conversation knowing what was built, why it is shaped that way, and what to do if it stops.
Write out the task the way it runs today: who does it, how often, which systems it touches, and what it has to produce at the end. Tell me whether anything already exists that I would be building on, and the date it needs to be working by. A screenshot of the spreadsheet, or of the screen the work happens on, tells me more than a requirements document usually does.