01Past project
Photography workflow
MyPhotoPicker
I built MyPhotoPicker for a part of photography that can take almost as much time as the shoot itself: choosing the final images. When a photographer delivers a large set of photos, the client needs a clear way to review them and identify their favorites. Sending files and lists back and forth can become confusing.
How it worked
The photographer could create a project and upload photos to it. The client would then sign in, look through the images, and select the ones they wanted. Instead of treating every photo as a separate email attachment, the project gave both sides one place to work through the selection process.
MyPhotoPicker had separate accounts for photographers and clients. The photographer managed each project, while the client could review and choose images without sending a long list of filenames back and forth.
It also handled touchup requests. If a client wanted an image retouched, they could flag that photo and the system would notify the photographer or a touchup artist about which images needed work. That helped connect the client's choices with the next step in editing.
I was also working on adding payment processing so clients could pay through the same system. That part was still in development. My goal was to bring selection, editing requests, and eventually payments into one workflow.
Photographer and client accountsProject galleriesImage uploadsClient selectionsRetouch requestsArtist notificationsPayments planned
02Past project
Document automation
Here's My Form
Here's My Form started with a practical question: why should someone have to rebuild an existing Word document just to collect answers online? Many businesses already use documents for applications, requests, intake forms, and internal paperwork. I wanted a way to use those documents as the starting point.
How it worked
The user uploaded a Word document and marked the places where answers belonged. A field was written with double curly brackets, such as {{Client Name}}, {{Address}}, or {{Phone Number}}. The application read those markers and turned them into fields in an online form.
After the fields were identified, the user could review the form and adjust the field types. It also supported default values inside a marker. For example, {{State::Texas}} created a field called State with Texas already filled in. Once the form was ready, it could be shared and the completed responses collected in one place.
I also added the ability to accept payments along with a completed form. That let someone use the same form to collect information and payment when a service, application, or request required both. The harder part was turning familiar Word document fields into information the browser could display and process.
Word document uploadPlaceholder parsingEditable field typesDefault valuesResponse collectionPayments
03Past project
Community web application
CherishLuv
CherishLuv was a dating website for adults. The idea was to make it easy for someone to create a profile, learn about other members, and begin a private conversation if there was mutual interest. It was a complete website concept rather than a single tool or form.
What members could do
Members could create an account, fill out and update their profiles, browse other people's profiles, upload and manage photos, and send private messages. Those are familiar features, but putting them together into one consistent experience is more involved than building a basic page.
The profile side of the site helped people share information about themselves. The photo tools gave members a way to manage how they appeared on the site. Private messaging provided a separate place for conversations after someone found a profile that interested them.
Member registrationEditable profilesPhoto managementProfile browsingPrivate messages
04Past project
AI and customer service
ChattyWolf
ChattyWolf was a website chatbot project aimed at smaller businesses. I built it around a simple problem: a potential customer may visit a website, have a question, and leave before anyone can answer. A useful assistant should be able to respond with the right business information and help the customer take the next step.
How it worked
The chatbot used information supplied by the business, including services, opening hours, service areas, general pricing, policies, and frequently asked questions. Instead of a generic chat window, the goal was to give visitors answers that reflected the specific business they were contacting.
It could also collect a visitor's name and contact details along with what they needed. That information could then be sent by email so the business had a chance to follow up. The original demo used a browser chat interface and a PHP endpoint for handling requests. It also kept a short conversation history so replies could follow the discussion.
AI chat interfaceBusiness informationConversation contextLead collectionEmail follow upPHP backend