3D printing filament calibration dashboard
As my 3D printing setup became more capable, the filament-management side became harder to trust. Bambu Studio stores filament presets, process profiles, printer settings, AMS material assignments, and K / Flow Dynamics calibration data in ways that are useful to the software but not always clear to the person trying to maintain a consistent setup.
The practical problem was simple: with multiple nozzle sizes, standard and high-flow hotends, left and right toolheads, and many filament presets, it became difficult to answer which values were actually calibrated and which ones were inherited defaults.
I started building a local calibration-management dashboard to make that information visible. The tool scans Bambu Studio filament preset files, pulls out the settings that matter most, and presents them in a searchable dashboard. It can compare profiles side by side, highlight meaningful differences, and help identify near-duplicate presets that should probably be cleaned up or consolidated.
A key part of the work was tracking K / Flow Dynamics values. Instead of relying only on Bambu Studio’s less visible printer-side calibration records, the tool stores calibration notes in a structured block inside the existing filament notes field. That keeps the information close to the filament profile, makes it human-readable, and preserves any notes that were already there.
The dashboard focuses on the settings that affect real printing decisions: flow ratio, maximum volumetric flow, temperatures, cooling, nozzle and hotend context, and calibration values. The goal is not to replace Bambu Studio, but to make its preset data easier to audit and maintain.
I built the first version in Python with a Streamlit interface so it could be tested quickly on macOS and Windows. Because the tool edits local preset files, I treated safety and reversibility as part of the design. Before writing changes, it creates backups, validates the JSON files, and logs what changed so the workflow is easier to trust.
This is a personal tooling project, but it reflects a broader process-improvement pattern: when a system becomes too complex to manage reliably by memory, make the important information visible, comparable, backed up, and easier to maintain.
Automated event photo upload and print station
This project supported The Big DV public installation by making one of the interactive pieces easier for guests and volunteers to use. The installation invited people to contribute photos and design responses to a public wall, so the workflow needed to move images from a guest’s phone to a volunteer-operated photo printer without creating a messy manual process during the event.
Keeping the public interaction simple
The visible workflow had to be simple: scan a QR code, upload a photo, and let the volunteers print it. I did not want guests handing over phones, emailing files, or relying on a volunteer to troubleshoot every submission. That meant the technical side could be more complicated, but the public side could not be. The system needed to feel like a normal event interaction, not a tech demo.
Making the hidden workflow do the work
I connected a Dropbox File Request, Dropbox webhook, Cloudflare Worker, Join, Tasker, Autosync, and a Samsung Tab A9+ into one operating workflow. Uploaded images triggered the automation chain, the tablet was notified that new files were available, and Autosync moved them into a local folder the SELPHY printing app could read. For volunteers, the result was straightforward. Open the printing app, find the submitted photos, and print. They did not need to download files, search folders, move images around, or understand the automation chain behind it.
Designing for a live event
The setup also had to survive the realities of a public event. I configured the tablet more like a kiosk than a personal device, with separate accounts, minimal installed apps, public-use restrictions, and no unnecessary personal data exposed. I also built in fallback sync behaviour and failure alerts so the workflow was not dependent on someone noticing a problem at the exact moment it happened. Theft and recovery risk, account separation, volunteer handoff, and privacy exposure were all part of the design.
The final snapshot
I recognized the friction in a live public interaction and connected available tools into a workflow people could use without thinking about it. The system reduced volunteer handling, protected guest privacy better than an improvised process, and made the interactive part of the installation feel simple from the outside
Internal project startup workflow
As Process Improvement Manager at Pentillion Construction, I built an internal project startup workflow to improve the handoff between a project being awarded and the information needed to manage, bill, and administer the work.
Before the workflow, project information could be scattered across conversations, emails, estimates, and individual memory. One person might know the billing arrangement, another might know the site contact, and accounting might not have enough context to set up the job or invoice correctly. That created avoidable friction at exactly the point where the project needed to start cleanly.
The startup workflow was designed to make that information explicit. It captured project status, project lead, client and site contacts, expected costs, billing responsibilities, important dates, scope notes, permit requirements, file uploads, and trade-specific details. It also helped handle more complicated billing situations where costs might be split between property managers, tenants, landlords, or other clients.
I built the form with auto-populated dropdowns and conditional logic so it was easier to complete and did not ask every user every possible question. The form changed based on the project information being entered, which made it more practical for real use and reduced the chance that people would skip it because it felt too cumbersome.
I also configured the workflow so submissions were automatically emailed to the people who needed the information. That helped project managers, office administration, and accounting see new work earlier and with more consistent context.
The result was a clearer startup process for awarded work. The workflow reduced reliance on informal handoff, helped accounting understand billing requirements earlier, reduced the chance of missed invoices, and made complex project setup easier to coordinate. It was a small internal system, but it addressed a real operational problem: getting the right information to the right people before gaps turned into project or billing issues.
Date-night fitness challenge automation
My wife and I wanted a fun way to stay accountable with our fitness goals, so I built a shared challenge that turns Garmin activity data into a weekly scoreboard, a date-night fund, and a small amount of competitive pressure.
The rules are simple. Each week, the person with the fewest Garmin intensity minutes contributes $50 to the date-night fund. Zone 5 training minutes count double, so harder training gets extra credit. Each person is also expected to complete two weight-training sessions per week, and missing one adds another $25 penalty. After four weeks, the winner chooses the date night and can delegate the planning and organizing to the other person.
That structure made the challenge playful instead of purely punitive. The “penalty” still goes toward something shared, and the four-week cycle gives the challenge a clear finish line before it starts again.
The system only works if the tracking does not become a chore, so I automated the boring parts. Scripts pull activity data from Garmin, sync it into Google Sheets, backfill historical activity, calculate weekly standings, apply the contribution rules, and send a daily email showing who is ahead, who is behind, and what needs to happen before the week ends.
Google Sheets became the visible scoreboard and rule engine. It keeps the calculations transparent enough that the challenge does not feel like a black box, while the automation removes the need to manually copy workouts, compare activity minutes, or remember to send updates.
The daily email is a key part of the design. It makes the challenge visible without requiring either of us to open a dashboard every day. That small reporting loop keeps the system present in normal life and makes it easier to adjust before the end of the week.
This is a personal project, but the pattern is transferable: define the behaviour you want, make the rules visible, automate the tedious parts, and turn feedback into something people actually pay attention to. In this case, the result is a fitness challenge that supports consistency, competition, and date nights without creating another manual tracking task.
Trello-based maintenance management system
At Pentillion Construction, I implemented a Trello-based maintenance management and documentation system for recurring work across a dozen commercial properties. The work involved routine inspections, seasonal tasks, urgent repairs, subcontractor follow-up, site-specific knowledge, safe work practices, and a lot of small details that needed to be available when someone was actually on site.
I had previously worked in the maintenance technician role myself, so I understood how quickly the work could become difficult to track when the system depended on phone calls, personal notes, memory, and individual site knowledge. A technician might visit several properties in a day, deal with routine checks, unexpected issues, tenant concerns, small repairs, and subcontractor coordination, then still need to remember what should happen next week, next month, or next season.
The problem was not that people were not trying. The problem was that too much important information lived in separate places. If a task, photo, decision, manual, contact, or site detail only lived in one person’s memory or text messages, it was too easy for context to be lost, the same questions to be asked repeatedly, or follow-up work to become invisible.
Building the boards around the real maintenance workflow
I structured the system with dedicated Trello boards for each site and a general knowledge board for shared procedures, sourcing information, contacts, safe work practices, and recurring references. Each site board was organized to track active tasks, completed work, projects, recurring templates, and site information.
Cards became the working record for each issue or task. They could hold checklists, photos, comments, links to manuals, storage locations, water shutoff information, sourcing notes, and other details that are easy to lose but important when someone is standing in the building trying to solve the problem.
The system was designed around how maintenance actually happens. Weekly, monthly, and seasonal template cards could be copied into the active task list with due dates, keeping recurring work visible before it became urgent. The recurring work included items such as filter changes, bird checks, vacancy checks, janitorial reviews, fire and generator tests, exterior lighting checks, pest inspections, equipment servicing, salting preparation, annual fire and pump checks, anchor inspections, painting reviews, and pressure washing reviews.
Making responsibility and follow-up visible
I also built the workflow around accountability. Cards are assigned to the person responsible for seeing the task through. Priority labels help show what needs attention first, and subcontractor labels identify work that requires outside follow-up.
That structure matters because maintenance work often fails at the handoff. Someone notices an issue, someone else talks to a subcontractor, another person waits for a quote, and then the original context disappears. Keeping comments, photos, due dates, labels, and assignments on the same card makes the work easier to pick back up without needing a separate explanation.
The photo history became another important part of the system. Photos could document problems, site conditions, completed work, recurring issues, and past repairs. That created a practical historical record for planning, liability, trend review, and training.
Extending Trello with n8n reporting
Trello’s built-in automation handled some recurring task creation, but it had limits when the system had to scale across multiple users and sites. To extend it, I connected Trello to n8n and used API queries and filtering to build custom reporting.
The system can send HTML email reports with direct links back to the relevant Trello cards. Reports can summarize completed work, upcoming tasks, overdue items, assigned responsibilities, due dates, labels, subcontractor follow-up, and other filtered information across all sites.
A weekly report gives a snapshot of what was completed and what still needs attention. Upcoming-task emails help keep maintenance visible before it becomes urgent, making it easier for the technician to plan ahead, pick up materials, or coordinate subcontractors before arriving on site. Reports can also be tailored for different people depending on their role, including the maintenance technician, me acting as maintenance manager, and ownership.
Creating a company knowledge base
The maintenance system also became a knowledge base. It gave the company a practical place to store manuals, procedures, site-specific details, photos, sourcing notes, contacts, and institutional knowledge that would otherwise stay with whichever person happened to know it.
That made the system useful beyond daily task tracking. It helped new people learn the sites faster, gave management better visibility into maintenance activity, and created a stronger record of what was done, when it was done, and why.
Handoff and refinement
This project combined my experience in the maintenance role with process improvement, workflow design, documentation, automation, training, and hands-on implementation. I designed the board structure, templates, labels, due-date logic, automations, reporting, documentation, and training materials, then continued checking in with users to refine the system around how the work actually gets done.
Information needs a home
The result was a maintenance workflow that captured more site knowledge, made responsibilities clearer, improved follow-up, reduced reliance on individual memory, and helped recurring work stay visible.
This is one of the clearest examples of the kind of system I like building. The system is useful because it gives people an operating structure: less lost context, better handoff, clearer accountability, and enough automation that important work is harder to forget.
Maintenance performance dashboard
At Pentillion Construction, the property maintenance role covers a wide range of responsibilities across roughly a dozen commercial properties, including outdoor malls, tenant spaces, and mixed-use sites. The work includes routine inspections, garbage removal, cleaning, minor repairs, contractor coordination, task tracking, and responding to issues raised by tenants, property managers, and owners.
Although the role is important, the expectations were not always easy to define. Good maintenance often goes unnoticed. When the work is done well, tenants and customers simply experience a clean, functional, well-managed property. That can make the role feel thankless, but it also makes clear expectations more important.
Small visible issues, such as mud on a front door, overflowing garbage, or damaged finishes, can quickly create complaints and reduce confidence in the maintenance team. I identified a need to better define what successful performance looked like for the maintenance role, especially because the job required more than simply completing assigned tasks.
Technicians needed to take ownership of their sites, understand priority and billing boundaries, use Trello consistently, communicate clearly, and know when work should be escalated or subcontracted rather than handled in-house.
To address that, I created a job dashboard for the Property Maintenance Technician role. The dashboard condensed the role into four key performance areas: Site Ownership & Accountability, Task Management & Prioritization, Communication & Coordination, and Professionalism & Tenant Interaction.
Each category included a plain-language summary, detailed expectations, measurable indicators, and reflection prompts that could be used for onboarding, coaching, and performance discussions. The idea was to make the role easier to understand without reducing it to a checklist of disconnected tasks.
The dashboard helped translate informal feedback into a shared standard. Instead of expectations being passed along through phone calls or individual training styles, the technician had a clear reference point for what mattered most: keeping sites visibly cared for, tracking tasks properly, spending time on approved work, communicating before problems escalated, and identifying work that should be handled by outside contractors.
The result was clearer role definition for new hires and existing technicians. It reduced billing mistakes, encouraged more consistent use of Trello, and helped management evaluate performance more fairly. It also reinforced the larger operational goal: maintenance should create confidence. Property managers, owners, tenants, and customers should be able to see that the site is being looked after, even when the best result is that nothing appears to be wrong.
Structured knowledge systems: Notion + Obsidian
I built a personal knowledge and fitness organization system using Notion and Obsidian to make health, training, and body-mechanics information easier to capture, structure, and reuse.
The goal was not just to take notes. I wanted a system where useful information could be found again, updated over time, and connected to future decisions. Notion became the structured database side of the workflow, while Obsidian became the long-term knowledge base for health, anatomy, movement, recovery, supplements, and body-mechanics notes.
The original trigger was a fitness challenge that provided an exercise schedule, but I wanted more than a simple list of workouts. I wanted to track weights and reps, reuse exercises in future routines, attach notes, add links and videos, and build a system that could evolve as my understanding improved.
Static notes were not enough. As I learned more about fitness, movement, posture, recovery, and the body, information would get scattered, repeated, or forgotten. It was difficult to turn what I had learned into something useful later.
In Notion, I created a structured fitness database system with separate areas for workouts and exercises. The exercise library acts as the stable reference layer, where each exercise can hold notes, links, videos, technique cues, and future updates. Workout routines can then reference those exercises without duplicating information.
This makes the system more useful than a simple spreadsheet or static program. A workout item can link back to a reusable exercise page, and that exercise page can continue to improve over time as I learn more.
In Obsidian, I use a separate health knowledge base for connected notes about the body, movement, recovery, supplements, and related concepts. Obsidian is better suited for cross-linking ideas, adding references, and building a web of knowledge where one topic can connect naturally to another.
The two systems serve different roles. Notion handles structured fitness tracking, exercise databases, workout scheduling, weights, reps, notes, links, and reusable exercise records. Obsidian handles long-term health knowledge, body-mechanics notes, linked references, concepts, and learning that benefits from cross-linking.
This project reflects how I approach information-heavy problems. I do not want useful knowledge to disappear into scattered notes or one-off conversations. I want it captured in a place where it can be retrieved, improved, and applied later.
The same mindset applies well beyond personal fitness. Engineering and project work often involve technical decisions, assumptions, lessons learned, stakeholder input, constraints, and repeated problem-solving. Information only has lasting value if it can be found and reused when it matters.
This system is personal in application, but professional in mindset: identify the friction, design a structure, separate reference information from action tracking, and build a workflow that improves over time.
