{"version":"https://jsonfeed.org/version/1.1","title":"Engineer — Portfolio","home_page_url":"https://engineer.company/","feed_url":"https://engineer.company/feed.json","description":"Engineer ApS — software development \u0026 IT consulting in Copenhagen, Denmark. A portfolio of proven engineering achievements across software, data, cloud and IT.","language":"en","items":[{"id":"https://engineer.company/portfolio/increased-brand-popularity-by-200x-through-successful-brand-1/","url":"https://engineer.company/portfolio/increased-brand-popularity-by-200x-through-successful-brand-1/","title":"Increased brand popularity by 200x through successful brand development across offline and online platforms.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Engineer ApS was a brand‑new consultancy with real technical depth and almost nobody who\u0026rsquo;d heard of it. That\u0026rsquo;s a specific kind of frustrating: the skill is there, the work would be good, but none of it matters if the clients and partners who\u0026rsquo;d want it don\u0026rsquo;t know you exist. A young firm has to be seen before it can win anything.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to build a brand people would actually recognise — across both the offline and online sides — and to turn the firm\u0026rsquo;s engineering credibility into visible market presence, rather than leaving it as a well‑kept secret.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The brand was built deliberately and kept consistent. It started with a clear identity — a voice, a visual language, and a portfolio that led with concrete engineering outcomes instead of the vague \u0026ldquo;we deliver value\u0026rdquo; language everyone else uses. Then it ran across the channels that matter for this kind of firm — the website, LinkedIn, GitHub, in‑person events — with every touchpoint saying the same thing rather than each drifting off on its own. The throughline was leading with real case studies and real results, so the credibility was something you could see evidence for, not just a claim.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Brand reach grew around 200‑fold across the offline and online platforms — an unknown newcomer turned into something people actually recognised. And it wasn\u0026rsquo;t vanity reach; the visibility started producing a steady flow of inbound conversations and opportunities that simply hadn\u0026rsquo;t been there before.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/drove-brand-engagement-and-loyalty-by-100-through-2/","url":"https://engineer.company/portfolio/drove-brand-engagement-and-loyalty-by-100-through-2/","title":"Drove brand engagement and loyalty by 100% through market trend analysis and consumer behavior insights.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e As the visibility climbed, Engineer ApS was reaching more people — but the engagement was thin. People noticed and moved on; the early interest wasn\u0026rsquo;t turning into relationships that lasted. Reach without engagement is just noise, and the brand was making noise more than connections.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to deepen the engagement and the loyalty, and to do it by actually looking at what the market and the audience were responding to rather than trusting gut instinct.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e So the brand became data‑informed instead of intuition‑led. That meant looking at the market trends and how the audience actually behaved across the channels — not what anyone assumed they\u0026rsquo;d like, but what they demonstrably engaged with. It surfaced the topics and formats that drew real attention, and the content and outreach got steered toward those. The important part was tightening the loop: watch what landed, publish more of that shape next time, and let each cycle be a bit better‑aimed than the last.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Engagement and loyalty doubled — a 100% improvement — with an audience that came back and engaged rather than glancing once and leaving, and noticeably stronger relationships with prospects and partners. The brand stopped broadcasting into the void and started building something that returned.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-a-comprehensive-infrastructure-framework-for-dtu-impacting-3/","url":"https://engineer.company/portfolio/designed-a-comprehensive-infrastructure-framework-for-dtu-impacting-3/","title":"Designed a comprehensive infrastructure framework for DTU impacting 14 departments, featuring flexible modules, unified data pipelines, and structured support strategies for long‑term adoption.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e At a research institute comprising 14 diverse research groups, each group worked with varying data sources, formats, scales, and software tools. The technical expertise and available IT resources varied widely across the groups. While a few had managed to create and deploy custom IT solutions, many struggled with the complexity of their data infrastructure needs, diverting valuable time and focus from their core research work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to devise a solution that would allow researchers to focus on their scientific work rather than IT challenges. The goal was to design and implement a scalable, institute‑wide data infrastructure that could accommodate the broad and differing requirements of the majority of research groups.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A robust, forward‑thinking infrastructure plan was developed that balanced flexibility and standardization. The plan outlined key components such as modular architecture, integration pathways for diverse data sources, user‑friendly interfaces tailored to varying technical skill levels, and scalable storage and processing solutions. It also included strategies for onboarding, support, and governance to ensure adoption and sustainability.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The resulting infrastructure plan was both technically sound and strategically aligned with the institute’s research goals. It unified the vision for data management across the organization, provided a clear path to reducing IT burden on researchers, and laid the foundation for a shared, efficient, and future‑ready research data environment. The plan was well received for its inclusivity, clarity, and adaptability, setting a strong direction for the institute\u0026rsquo;s data infrastructure transformation.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/engineered-hourly-electricity-consumption-aggregation-pipeline-in-python-4/","url":"https://engineer.company/portfolio/engineered-hourly-electricity-consumption-aggregation-pipeline-in-python-4/","title":"Engineered hourly electricity consumption aggregation pipeline in Python / SQL / Bash + Jq, achieving 180ms for 30‑day datasets across heterogeneous JSONL sources.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The company processes large volumes of heterogeneous electricity data coming from multiple data sources, each with its own reporting frequency—ranging from hourly intervals to 15‑minute intervals, and in some cases, irregular timestamps. This variability poses a challenge when trying to create a coherent, comparable dataset. To support accurate energy analytics, this data needs to be normalized into consistent hourly consumption values, aggregated per zone.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The objective was to take raw event data from a historical dataset (in JSONL format) and convert it into hourly‑aligned electricity consumption figures, structured as one row per hour and per zone. Specifically, the task involved:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAligning timestamped data to strict hourly intervals,\u003c/li\u003e\n\u003cli\u003eAggregating total electricity production within each interval by summing mix values,\u003c/li\u003e\n\u003cli\u003eIncorporating cross‑border exchanges by adding imports and subtracting exports,\u003c/li\u003e\n\u003cli\u003eOutputting the final values in a structured, scalable format suitable for further analysis.\u003c/li\u003e\n\u003cli\u003eThe solution also needed to be efficient enough to scale for large time windows (30+ days) and across multiple countries/zones.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e To approach this task, three different variants of the solution were implemented using Python, JQ (for command‑line JSON processing), and SQL, each optimized for different contexts:\u003c/p\u003e\n\u003cp\u003ePython was chosen for its flexibility, ease of data manipulation, and ability to handle in‑memory transformations efficiently. Using pure Python functions, a pipeline was built that:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eParsed the JSONL files into structured data frames\u003c/li\u003e\n\u003cli\u003eResampled the time series data to hourly intervals\u003c/li\u003e\n\u003cli\u003eAggregated production and calculated net electricity consumption (production + imports − exports)\u003c/li\u003e\n\u003cli\u003eExported the results as CSV or loaded them into a lightweight SQLite database for inspection.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eJQ was used to create a quick, minimal‑dependency solution for command‑line environments, built as a JQ filter chain.\u003c/p\u003e\n\u003cp\u003eIn PostgreSQL the JSONL data was imported, normalized tables created, and a series of SQL queries written.\u003c/p\u003e\n\u003cp\u003eTo evaluate performance, each solution was benchmarked with both 1‑day and 30‑day historical datasets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The Python implementation emerged as the fastest and most scalable solution, completing:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e1‑day data processing in just 34ms\u003c/li\u003e\n\u003cli\u003e30‑day dataset in 180ms\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis confirmed its suitability for handling larger timeframes while maintaining sub‑second performance. It also offered clear, maintainable code that could be easily extended to multi‑zone processing or integrated into an ETL pipeline.\u003c/p\u003e\n\u003cp\u003eOverall, the multi‑tool approach demonstrated flexibility in tool usage, strong performance optimization, and robust handling of time‑alignment and aggregation challenges in real‑world electricity data pipelines.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/accelerated-geographical-data-pipeline-performance-by-50x-by-5/","url":"https://engineer.company/portfolio/accelerated-geographical-data-pipeline-performance-by-50x-by-5/","title":"Accelerated geographical data pipeline performance by 50x by improving SQL programming and data modeling across PostgreSQL, MS SQL, and Google Cloud BigQuery.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The organization faced significant delays in processing large sets of geographical data, which affected the efficiency of data‑driven decision‑making processes and analytical reporting.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The objective was to optimize the geographical data pipeline to enhance performance and reduce processing time, ensuring that data analytics could be performed more effectively and in real‑time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The existing SQL programming and data modeling structures across PostgreSQL, MS SQL, and Google Cloud BigQuery were meticulously analyzed, which surfaced bottlenecks related to inefficient indexing strategies, suboptimal query designs, and lack of appropriate constraints. To address these issues:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe data models were redesigned to normalize critical datasets, with partitioning strategies implemented to improve data retrieval times.\u003c/li\u003e\n\u003cli\u003eApplied advanced indexing techniques, including B‑tree and GiST indexes for PostgreSQL, filtered indexes in MS SQL, and clustering in BigQuery.\u003c/li\u003e\n\u003cli\u003eOptimized complex SQL queries by refactoring subqueries, reducing join operations, and incorporating materialized views where relevant.\u003c/li\u003e\n\u003cli\u003eEstablished data integrity constraints such as foreign keys and check constraints to ensure data consistency without compromising performance.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e These comprehensive optimizations accelerated the geographical data pipeline performance by 50x, significantly reducing data processing time. This improvement facilitated real‑time analytics, enhanced reporting capabilities, and empowered stakeholders with timely, data‑driven insights, ultimately contributing to more informed strategic decisions.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/improved-geographical-map-application-performance-by-10x-through-6/","url":"https://engineer.company/portfolio/improved-geographical-map-application-performance-by-10x-through-6/","title":"Improved geographical map application performance by 10x through strategic database transition from MSSQL to PostgreSQL, optimizing processing and data security.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The organization’s geographical map application, which supported real‑time spatial queries for many users, was experiencing severe performance bottlenecks. Latency in rendering map layers and querying location‑based data impacted both user experience and backend service reliability. The system was backed by a legacy Microsoft SQL Server (MSSQL) database that lacked native geospatial indexing.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Improve the performance, scalability, and security of the map application, with a specific goal of reducing query latency and increasing throughput for spatial operations.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Led a strategic database migration from MSSQL to PostgreSQL with the PostGIS extension to enable native geospatial support.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDesigned a new schema optimized for spatial data, introducing GIST and SP‑GiST indexes on geometry and geography columns for faster querying.\u003c/li\u003e\n\u003cli\u003eDefined strict foreign key and check constraints to ensure relational integrity and enforce data validation rules on spatial coordinates.\u003c/li\u003e\n\u003cli\u003eMigrated over 50 million spatial records using ETL pipelines with data transformation steps to conform to new SRID standards (EPSG:4326).\u003c/li\u003e\n\u003cli\u003eTuned PostgreSQL configuration parameters (e.g., work_mem, effective_cache_size) for optimal I/O performance under concurrent access.\u003c/li\u003e\n\u003cli\u003eImplemented role‑based access controls (RBAC) and row‑level security to enforce data protection policies across multiple user groups.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Achieved a 10x improvement in spatial query performance, reducing average response time from 2.5 seconds to under 250 milliseconds. Backend CPU load dropped by 65%, and system availability improved during peak usage. Security posture was also strengthened with granular access policies and data validation constraints, reducing potential for spatial data corruption.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/resolved-1-000-issues-in-geographical-data-and-7/","url":"https://engineer.company/portfolio/resolved-1-000-issues-in-geographical-data-and-7/","title":"Resolved 1 000 issues in geographical data and time‑series data, using GDAL, ArcGIS, PostGIS, Mapbox, QGIS, SQL (PL/pgSQL, Transact‑SQL), Bash, ensuring high‑quality big data processing.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e While working on a large‑scale geospatial analytics project, the team encountered numerous inconsistencies and anomalies within the geographical and time‑series datasets. These issues were affecting the accuracy of spatial analyses and decision‑making tools used across several departments.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The responsibility was to identify, resolve, and optimize over 1,000 data quality issues within these complex datasets to ensure the integrity and performance of downstream applications and visualizations.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Spatial errors were systematically diagnosed and corrected using a combination of tools, including GDAL, QGIS, and ArcGIS, with automated workflows implemented in Bash scripting to streamline recurring data cleaning tasks. PostGIS handled advanced spatial queries and spatial indexing, and robust procedures were written in PL/pgSQL and Transact‑SQL to manage and transform both geographic and temporal data within the PostgreSQL and SQL Server databases. Additionally, the cleaned data was integrated into interactive visualizations using Mapbox, enhancing data accessibility for end users.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Through these efforts, over 1,000 critical issues were resolved, significantly improving data accuracy and processing speed. This directly contributed to a 35% reduction in spatial query run times and enabled more reliable spatial analyses for the team. The work ensured that high‑quality, ready‑to‑use data was consistently available for analytics and reporting, supporting strategic decisions across the organization.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-implemented-and-administered-6-etl-elt-pipelines-8/","url":"https://engineer.company/portfolio/designed-implemented-and-administered-6-etl-elt-pipelines-8/","title":"Designed, implemented, and administered 6 ETL/ELT pipelines, utilizing Google BigQuery, MSSQL, PostgreSQL, Shell scripting, PL/pgSQL, and Transact‑SQL, integrating data for efficient Python API processing.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The organization needed to consolidate and process large volumes of structured data from a remote data warehouse located behind an IPSec VPN. This data was crucial for powering internal analytics dashboards and external Python APIs used by clients and partners.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The objective was to design, implement, and maintain a set of robust and automated ETL/ELT pipelines to securely retrieve, transform, and load data into Google BigQuery, ensuring data accuracy, performance, and scalability across systems.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e 6 end‑to‑end ETL/ELT pipelines were designed, implemented, and administered, spanning multiple technologies including Google BigQuery, MSSQL, PostgreSQL, Shell scripting, PL/pgSQL, and Transact‑SQL.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEstablished secure connections to a remote server protected by an IPSec VPN to automate data retrieval.\u003c/li\u003e\n\u003cli\u003eScheduled and executed downloads of compressed data archives containing Parquet, CSV, and .bak files.\u003c/li\u003e\n\u003cli\u003eDeveloped Bash and Python scripts to extract and classify files based on type and schema.\u003c/li\u003e\n\u003cli\u003eFor .bak files, backups were restored into a local MSSQL Server instance using RESTORE DATABASE workflows and schema integrity validated.\u003c/li\u003e\n\u003cli\u003eLoaded structured data into staging schemas in MSSQL and PostgreSQL, using bcp, psql, and SSIS tools, depending on the source format.\u003c/li\u003e\n\u003cli\u003eWrote modular and reusable PL/pgSQL and T‑SQL procedures to clean, normalize, and enrich the data based on business logic.\u003c/li\u003e\n\u003cli\u003eExported curated datasets and tables into intermediate formats, compressed them using gzip, and securely transferred them to a Google Cloud Storage bucket.\u003c/li\u003e\n\u003cli\u003eAutomated the upload and schema mapping processes to Google BigQuery, using bq CLI and Python‑based data ingestion scripts.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e These automated pipelines significantly reduced the manual overhead and processing time—from 3+ hours of manual work to under 20 minutes end‑to‑end, while improving data freshness from weekly to daily syncs. The Python APIs consuming this data saw a 30% performance improvement, and the enhanced visibility helped business analysts deliver faster insights to stakeholders. The solution remains scalable and extensible for onboarding new data sources as the business grows.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/developed-and-launched-the-company-s-first-observability-9/","url":"https://engineer.company/portfolio/developed-and-launched-the-company-s-first-observability-9/","title":"Developed and launched the company's first observability dashboard, providing real‑time system performance insights and data visualization on the large office TV.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The company was facing challenges in monitoring real‑time system performance, which often led to delayed incident responses and reduced visibility into infrastructure health. There was no centralized solution in place for teams to gain insights into operational metrics.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to develop a solution that would enable technical and non‑technical stakeholders to monitor key system metrics in real time, with a focus on accessibility, clarity, and proactive issue detection.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The company\u0026rsquo;s first observability dashboard was designed and implemented, collecting all essential system metrics — such as CPU, RAM, HDD, temperature, and more — from remote Linux servers via SSH. Even Docker containers were monitored using this method. Later, a second version was designed and implemented using Grafana and Prometheus for more advanced visualization and monitoring capabilities. Collaboration with DevOps and engineering teams identified the critical metrics, such as CPU utilization, memory usage, service uptime, and API latency. Data pipelines were configured to ingest and process performance metrics from various systems, and the dashboard deployed on a large office TV screen for maximum visibility. Alerting mechanisms for threshold breaches were also integrated to enable immediate action.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The dashboard significantly improved system transparency and response time to operational issues. Teams were able to detect and resolve incidents 40% faster. It also fostered a culture of shared ownership over system health by making performance data accessible to everyone in the office, ultimately contributing to a more stable and efficient production environment.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/delivered-8-power-bi-projects-with-comprehensive-manuals-10/","url":"https://engineer.company/portfolio/delivered-8-power-bi-projects-with-comprehensive-manuals-10/","title":"Delivered 8 Power BI projects with comprehensive manuals, integrating Microsoft Power BI tools with NodeJS API and Python FastAPI for effective data analytics and visualization.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The organization needed dynamic, visual insights into complex datasets involving electrical grid performance and geographical distribution metrics to support decision‑making across technical and strategic teams.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Develop interactive dashboards and reporting solutions that could effectively present both real‑time and historical geographical and electrical data, enabling stakeholders to quickly identify trends, anomalies, and performance indicators.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Integrated Microsoft Power BI with a custom backend stack using NodeJS API and Python FastAPI to streamline data ingestion, transformation, and visualization. Designed and implemented dashboards with map visualizations, energy consumption metrics, outage tracking, and grid efficiency indicators. Developed reusable templates and detailed documentation to support scalability and ease of use.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Successfully delivered 8 data analytics projects, improving report generation efficiency by 60% and enabling cross‑functional teams to make faster, data‑driven decisions. Stakeholders reported a significant increase in understanding of regional electrical performance and resource planning accuracy.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/released-500-electricity-and-gis-data-analysis-reports-11/","url":"https://engineer.company/portfolio/released-500-electricity-and-gis-data-analysis-reports-11/","title":"Released 500 electricity and GIS data analysis reports, utilizing deep research and troubleshooting to ensure accurate geographic and time series big data insights.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The team managed vast datasets generated by smart‑meters installed across multiple geographic regions. These smart‑meters produced granular, time‑series electrical consumption data used by energy analysts, engineers, and regional planners for operational and strategic decision‑making.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The responsibility was to produce high‑quality, transparent, and reproducible analytical reports that could uncover patterns in energy consumption, detect anomalies, and identify regional usage trends, while ensuring non‑technical stakeholders could easily interpret and reuse the findings.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e 500+ in‑depth data analysis reports were created and delivered, using pure SQL to perform all data extraction, transformation, and analysis tasks, working directly within cloud‑based environments such as PostgreSQL and BigQuery. The data included geolocation coordinates, meter IDs, timestamped energy usage, and environmental metadata. The SQL scripts featured CTEs, window functions, subqueries, and geospatial joins, allowing for scalable and efficient processing.\u003c/p\u003e\n\u003cp\u003eEach report included annotated SQL code, enabling colleagues and collaborators to fully reproduce and audit the research, which significantly reduced the time needed for follow‑up analysis. Troubleshooting notes were also added and common data quality issues documented, such as missing GPS coordinates or corrupted meter values, with recommended handling procedures.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The reports became a standard reference across departments, aiding in regional load balancing, energy efficiency planning, and anomaly detection. By ensuring full transparency and reproducibility, the work helped improve stakeholder trust in the data and contributed to more accurate forecasting models and a 10–15% improvement in operational planning efficiency.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/architected-created-and-managed-100-postgresql-ms-sql-12/","url":"https://engineer.company/portfolio/architected-created-and-managed-100-postgresql-ms-sql-12/","title":"Architected, created, and managed 100 PostgreSQL, MS SQL, and Google BigQuery data warehouse databases with primarily GIS and time‑series data, optimizing performance and scalability.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e In a rapidly growing tech company, there was a critical need to create, manage, and optimize a diverse portfolio of 100+ databases across PostgreSQL, Microsoft SQL Server, and Google BigQuery. These databases primarily handled complex datasets, including geographic information systems (GIS) data (e.g., spatial coordinates, and location‑based analytics) and time‑series data (e.g., sensor readings, logs, and real‑time metrics). The existing infrastructure faced challenges with scalability, query performance, and data consistency, particularly as the volume of data increased exponentially. The organization required a robust architecture to ensure data reliability, and reduce operational costs.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The primary objective was to design, implement, and manage a scalable, high‑performance data warehouse ecosystem tailored for GIS and time‑series data. This involved:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAddressing performance bottlenecks in complex spatial and time‑based queries.\u003c/li\u003e\n\u003cli\u003eEnsuring scalability to handle growing data volumes while maintaining cost efficiency.\u003c/li\u003e\n\u003cli\u003eCollaborating with cross‑functional teams (e.g., data scientists, product managers) to align database design with business needs.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e To achieve these goals:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eDesigned Scalable Architectures:\u003c/li\u003e\n\u003c/ol\u003e\n\u003cul\u003e\n\u003cli\u003eCreated normalized and denormalized schemas for PostgreSQL and SQL Server, leveraging spatial indexing (e.g., PostGIS for PostgreSQL) and time‑series partitioning to optimize query performance.\u003c/li\u003e\n\u003cli\u003eUtilized BigQuery’s time‑partitioned and clustered tables for efficient handling of large‑scale time‑series data.\u003c/li\u003e\n\u003c/ul\u003e\n\u003col start=\"2\"\u003e\n\u003cli\u003eImplemented Optimization Strategies:\u003c/li\u003e\n\u003c/ol\u003e\n\u003cul\u003e\n\u003cli\u003eIntroduced query optimization techniques, such as indexing, materialized views, and caching, to reduce latency for GIS and time‑series queries.\u003c/li\u003e\n\u003cli\u003eApplied data compression and columnar storage in BigQuery to minimize storage costs and improve scan speeds.\u003c/li\u003e\n\u003c/ul\u003e\n\u003col start=\"3\"\u003e\n\u003cli\u003eCollaborated on Cross‑Platform Integration:\u003c/li\u003e\n\u003c/ol\u003e\n\u003cul\u003e\n\u003cli\u003eDocumented best practices for GIS and time‑series data modeling to guide teams in future projects.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The initiatives led to significant improvements:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePerformance Gains: Query response times for GIS and time‑series data decreased by 40–60%, enabling faster analytics and decision‑making.\u003c/li\u003e\n\u003cli\u003eOperational Reliability: Automated monitoring reduced downtime by 50%, while standardized processes improved team productivity and reduced errors.\u003c/li\u003e\n\u003cli\u003eBusiness Impact: The optimized infrastructure enabled the company to launch new data‑driven products (e.g., real‑time analytics dashboards) and meet regulatory compliance requirements for data governance.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis work solidified the organization’s ability to handle complex data challenges.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-deployed-and-maintained-10-postgresql-and-ms-13/","url":"https://engineer.company/portfolio/designed-deployed-and-maintained-10-postgresql-and-ms-13/","title":"Designed, deployed, and maintained 10 PostgreSQL and MS SQL servers on Ubuntu Linux VPS, ensuring optimal server performance and reliability.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e As a DevOps engineer at a mid‑sized tech company, the task was managing and optimizing database infrastructure to support a growing user base and critical business applications. The organization relied heavily on PostgreSQL and Microsoft SQL Server for data storage and analytics, requiring high availability, scalability, and security.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The primary responsibility was to architect, deploy, configure, and maintain 10 PostgreSQL and MS SQL Server instances on Ubuntu Linux VPS environments. This included ensuring optimal performance, implementing robust security protocols, and establishing proactive monitoring to prevent outages. Additionally, the task included scaling the infrastructure to accommodate future growth while minimizing costs and maintaining compliance with industry standards.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e 1. Deployment \u0026amp; Configuration:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eInstalled and configured PostgreSQL 14 and MS SQL Server 2019 on Ubuntu 20.04 LTS VPS instances, ensuring compatibility with the company’s applications.\u003c/li\u003e\n\u003cli\u003eSet up automated backups using \u003ccode\u003epg_dump\u003c/code\u003e for PostgreSQL and SQL Server Agent jobs for MS SQL, with retention policies and offsite storage.\u003c/li\u003e\n\u003cli\u003eOptimized server configurations (e.g., memory allocation, query caching, and connection pooling) to improve query performance and reduce latency.\u003c/li\u003e\n\u003c/ul\u003e\n\u003col start=\"2\"\u003e\n\u003cli\u003e\n\u003cp\u003eMonitoring \u0026amp; Maintenance:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eImplemented monitoring tools like Prometheus, Grafana, to track CPU, memory, disk I/O, and query performance metrics in real time.\u003c/li\u003e\n\u003cli\u003eConducted regular patching and updates for both databases and the Ubuntu OS to address security vulnerabilities and ensure compliance.\u003c/li\u003e\n\u003cli\u003eCreated custom scripts for log analysis.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eSecurity \u0026amp; Scalability:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eConfigured firewalls (UFW), enforced role‑based access control (RBAC) to protect sensitive data.\u003c/li\u003e\n\u003cli\u003eDocumented procedures for disaster recovery, including point‑in‑time restores and failover protocols.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e - Achieved 99.9% uptime across all 10 database servers.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eImproved query response times by 30% through configuration tuning and index optimization, enhancing application performance.\u003c/li\u003e\n\u003cli\u003eReduced manual maintenance tasks by 50% via automation, freeing up 10+ hours per month for strategic projects.\u003c/li\u003e\n\u003cli\u003eSuccessfully scaled the infrastructure to support a 40% increase in user traffic without service degradation, contributing to a 20% revenue growth in the following quarter.\u003c/li\u003e\n\u003cli\u003eReceived recognition from the CTO for implementing security best practices that prevented potential data breaches.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis experience solidified deep expertise in database management, DevOps automation, and infrastructure optimization, delivering reliable, secure, and scalable solutions for complex enterprise environments.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/enhanced-data-security-by-implementing-1-000-rbac-14/","url":"https://engineer.company/portfolio/enhanced-data-security-by-implementing-1-000-rbac-14/","title":"Enhanced data security by implementing 1 000 RBAC rules for developers, application instances, PostgreSQL, MS SQL, and other Linux servers, preventing unauthorized access; documented with Ansible automation.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The organization needed to strengthen access controls across multiple systems, including developer environments, application instances, PostgreSQL, MS SQL, and Linux servers. While the underlying RBAC model was straightforward, the challenge lay in managing over 1,000 individual rules to cover diverse user roles and system requirements. The goal was to ensure strict access restrictions without introducing complexity.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Implement a scalable RBAC solution by defining and enforcing 1,000+ rules for access control. This involved mapping permissions to specific roles (e.g., developers, application instances, database admins) and ensuring rules were applied consistently across all systems. The task also required documenting the rules and automating their deployment to avoid manual errors.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The approach focused on creating a simple, modular RBAC structure, breaking down permissions into clear, reusable categories (e.g., \u0026ldquo;read‑only access to production databases\u0026rdquo;). Using Ansible, the configuration of each rule was automated, ensuring consistency across environments. For example, developers were granted access only to their designated servers, while application instances had limited permissions to prevent lateral movement. The process prioritized clarity over complexity, with each rule explicitly tied to a specific role and system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The implementation secured over 1,000 rules without introducing unnecessary complexity, reducing unauthorized access risks by 85%. Automation streamlined deployment, cutting setup time by 60% compared to manual methods. The documented framework allowed teams to quickly audit or modify rules, ensuring scalability as the infrastructure grew. By focusing on simplicity and volume, the solution achieved robust security while maintaining operational efficiency.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/accelerated-postgresql-performance-by-10x-via-strategic-indexing-15/","url":"https://engineer.company/portfolio/accelerated-postgresql-performance-by-10x-via-strategic-indexing-15/","title":"Accelerated PostgreSQL performance by 10x via strategic indexing, partitioning, and query optimization, enhancing database efficiency for user, tenant, geospatial, and time‑series electrical data.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The PostgreSQL database served a mid‑sized application managing user accounts, tenant information, geographical data (e.g., locations, regions), and daily electrical consumption metrics. While the system operated under low traffic, performance issues emerged as data volumes grew. Queries involving geospatial data and time‑series electrical logs became sluggish, leading to inconsistent response times. The lack of optimized indexing, fragmented queries, and unpartitioned tables exacerbated the problem, creating bottlenecks for critical operations like user authentication, tenant management, and data reporting.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The goal was to enhance database performance by 10x without overhauling the existing architecture. The focus was on optimizing query execution, reducing latency, and ensuring scalability for future data growth. Key priorities included improving response times for geospatial and time‑based queries, minimizing resource contention, and maintaining data integrity while implementing changes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e 1. \u003cstrong\u003eIndexing:\u003c/strong\u003e Analyzed frequently queried columns (e.g., user IDs, tenant IDs, geospatial coordinates) and created targeted indexes. For geospatial data, GiST indexes were added to speed up spatial queries. Composite indexes were introduced for multi‑column filters, such as tenant ID + date ranges for electrical data.\u003cbr\u003e\n2. \u003cstrong\u003ePartitioning:\u003c/strong\u003e Implemented time‑based range partitioning for the electrical data table, splitting it by day/month. This reduced the dataset size for queries and improved scan efficiency. For geographical data, hash partitioning was used to distribute load evenly across nodes.\u003cbr\u003e\n3. \u003cstrong\u003eQuery Optimization:\u003c/strong\u003e Rewrote complex queries to avoid full table scans, leveraging CTEs (Common Table Expressions) and materialized views for frequently accessed datasets. The \u003ccode\u003eEXPLAIN ANALYZE\u003c/code\u003e tool identified inefficient joins and subqueries, which were restructured for better execution plans. Additionally, query caching and connection pooling were configured to reduce overhead.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Post‑optimization, query response times improved by 10x, with critical operations (e.g., user authentication, geospatial lookups) executing in milliseconds. The database’s resource utilization dropped by 40%, allowing the system to handle increased data volumes without performance degradation. Users reported smoother interactions, and the system became more scalable for future growth. The changes also reduced the need for hardware upgrades, saving costs while ensuring long‑term reliability. This project demonstrated how strategic indexing, partitioning, and query refinement can transform even low‑load systems into efficient, future‑ready databases.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/automated-gis-saas-application-deployment-data-processing-and-16/","url":"https://engineer.company/portfolio/automated-gis-saas-application-deployment-data-processing-and-16/","title":"Automated GIS SaaS application deployment, data processing, and reporting system using GitHub Actions CI/CD, Python, Bash, and SQL.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e At Utiligize, getting the GIS SaaS app deployed, processing its data and producing the reports were all manual steps — and manual steps are both slow and quietly dangerous. Every release ate engineering time and carried the chance of a slip, and the recurring data and reporting work sat there eating capacity week after week.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Automating the whole path from code to production, plus the recurring data‑processing and reporting, was the task — the goal being releases that were fast, safe and repeatable rather than a careful manual ritual each time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The whole path got automated. GitHub Actions pipelines took over the test‑build‑deploy cycle, so a release stopped depending on someone remembering the steps. The recurring data processing and the reports moved into scheduled Python, Bash and SQL jobs, so they just ran instead of being someone\u0026rsquo;s chore. And the configuration and secrets were standardised so every environment behaved identically — which is what kills the \u0026ldquo;works on my machine\u0026rdquo; surprises, because there stops being a \u0026ldquo;my machine\u0026rdquo; that\u0026rsquo;s different from production.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Deployment, data processing and reporting all became automated and reliable, the manual toil came off the team\u0026rsquo;s plate, and the release cycle got shorter. The team could put its attention on the product instead of the operations wrapped around it.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/automated-delivery-of-20-gis-data-pipelines-and-17/","url":"https://engineer.company/portfolio/automated-delivery-of-20-gis-data-pipelines-and-17/","title":"Automated delivery of 20 GIS data pipelines and app data ETL processes, streamlining infrastructure automation and reporting.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The platform ran on a lot of GIS data pipelines and application‑data ETL processes, and they were being delivered and watched by hand. Hand‑run pipelines create bottlenecks, they drift out of consistency, and worst of all they carry a constant low risk that one quietly fails and nobody notices until the data\u0026rsquo;s already wrong downstream.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Automating the delivery of those pipelines and ETL processes — so the data flowed reliably and predictably without someone shepherding it — was the task.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Twenty GIS data pipelines and the application‑data ETL came under automated delivery, end to end. The scheduling, the logging and the failure handling got standardised, so every pipeline behaved the same way and, crucially, you could see when one didn\u0026rsquo;t — a silent failure is only silent if nothing\u0026rsquo;s watching. And they were folded into the existing infrastructure automation and reporting, so they were part of one coherent system rather than a drawer full of scripts someone had to remember to run.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e All twenty pipelines and their ETL ran automatically and predictably, and the whole infrastructure‑automation and reporting picture got tidier for it. The business got dependable, current data without anyone having to walk it through by hand — and without the quiet‑failure risk hanging over it.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/automated-100-critical-data-backups-using-barman-google-18/","url":"https://engineer.company/portfolio/automated-100-critical-data-backups-using-barman-google-18/","title":"Automated 100 critical data backups using Barman, Google Cloud, Bash, and Python, ensuring data integrity across databases.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The critical GIS data, the application instances and the databases were scattered across systems with backups that were inconsistent and partly manual. For a product that lives on its data, that\u0026rsquo;s not a risk you can leave sitting — and the day you actually need a backup is precisely the worst day to find out it was incomplete.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to guarantee that all the critical data could be recovered, which meant automating comprehensive, verified backups across the whole estate — verified being the word that matters.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The backup regime was built end to end. A hundred critical data backups got automated, with Barman handling the PostgreSQL side and Google Cloud holding the offsite copies, and the whole thing was orchestrated and validated with Bash and Python — because a backup you\u0026rsquo;ve taken but never checked isn\u0026rsquo;t really a backup, it\u0026rsquo;s a hope. So there were retention policies to keep them current and integrity checks to confirm each one was actually good, not just present.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Backups ran automatically and were verifiable across every database, which turned data recoverability from an assumption into something tested. A major operational risk came off the business and got replaced with a recovery path you could actually trust — the difference being that this one had been checked, not just configured.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/deployed-and-maintained-20-docker-containerized-applications-troubleshooting-19/","url":"https://engineer.company/portfolio/deployed-and-maintained-20-docker-containerized-applications-troubleshooting-19/","title":"Deployed and maintained 20 Docker containerized applications, troubleshooting with Podman and Kubernetes, and managing R‑based apps on Google Cloud and AWS.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e There was a growing set of containerised applications — including some R‑based analytics apps — running across both Google Cloud and AWS. Spread over two clouds and a few container runtimes, they needed to deploy consistently and to be diagnosable quickly when something went wrong, which is harder than it sounds when no two environments are quite the same.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Deploying and maintaining those workloads reliably, and being able to diagnose problems fast across the runtimes and clouds, was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The containerised estate was managed across both clouds — twenty Docker applications deployed and maintained with consistent configuration and monitoring, so they weren\u0026rsquo;t each their own snowflake. When things went wrong, troubleshooting went through Podman and the orchestration debugging through Kubernetes. The R‑based analytics apps got dedicated attention in the Google Cloud and AWS production environments, kept stable and reproducible, which for analytics matters — a result you can\u0026rsquo;t reproduce isn\u0026rsquo;t much of a result.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The containerised estate ran reliably across both clouds, problems got diagnosed faster, and deployments stayed stable and reproducible. The applications the product leaned on stayed dependable no matter which cloud they happened to be running in.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/managed-30-ubuntu-linux-vps-instances-implementing-disaster-20/","url":"https://engineer.company/portfolio/managed-30-ubuntu-linux-vps-instances-implementing-disaster-20/","title":"Managed 30 Ubuntu Linux VPS instances, implementing disaster recovery strategies and ensuring optimal network configurations.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Utiligize ran on a fleet of Ubuntu Linux VPS instances whose setup had grown organically over time — which is a polite way of saying it had accumulated rather than been designed. That left gaps: inconsistent configurations, and recovery and networking arrangements that were more historical accident than plan.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to get the fleet under proper management, harden the disaster‑recovery side, and make the network configuration consistent and sensible across every instance.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The thirty instances came under deliberate management — treated as one coherent fleet rather than thirty individual pets. Real disaster‑recovery went in: backups, and restore procedures that were actually tested, because an untested restore is just a theory. And the network configuration was standardised for security and performance, so every instance followed the same hardened baseline instead of whatever it had happened to end up with.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The infrastructure became resilient and consistent, with recovery paths that had been tested and networking you could rely on. The downtime risk dropped, and the business ended up with a dependable foundation to grow on rather than a patchwork it had to keep nursing along.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/prevented-security-breaches-by-leading-access-management-initiatives-21/","url":"https://engineer.company/portfolio/prevented-security-breaches-by-leading-access-management-initiatives-21/","title":"Prevented security breaches by leading access management initiatives, utilizing M365, 1Password, Red Hat SSO, and OKTA SSO.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Access to systems and services across Utiligize was managed inconsistently — permissions granted ad hoc, over time, by different people. That\u0026rsquo;s a double problem: it opens the door to access nobody intended, and it makes auditing nearly impossible, because nobody can actually say who can reach what, or why they can.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The goal was to close off the security exposure by centralising and tightening access management across the whole organisation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The overhaul consolidated the identities and access across M365, 1Password, Red Hat SSO and OKTA SSO, so there was a coherent picture instead of scattered per‑system permissions. Least privilege was enforced — people and systems having exactly what they needed and nothing spare — and the onboarding and offboarding standardised, so access got granted and, just as importantly, revoked promptly and consistently rather than lingering after someone had moved on.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The unauthorised‑access risk dropped sharply and access became auditable and consistent — you could finally answer \u0026ldquo;who can reach this, and why.\u0026rdquo; The odd part is it also made daily life simpler for the team: the right doors opened easily and the wrong ones stayed shut, which is what good access management actually feels like.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/mitigated-operational-risks-by-implementing-a-monitoring-dashboard-22/","url":"https://engineer.company/portfolio/mitigated-operational-risks-by-implementing-a-monitoring-dashboard-22/","title":"Mitigated operational risks by implementing a monitoring dashboard using Grafana and Prometheus, improving system reliability.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Problems at Utiligize usually got noticed after they\u0026rsquo;d already hit users, because there was no single view of how the systems were doing. Without that visibility the team was permanently on the back foot — reacting to things that had already gone wrong instead of seeing them coming.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to cut the operational risk by giving the team real‑time visibility into the systems they depended on.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The observability layer was built out. A monitoring dashboard on Grafana and Prometheus, the key services instrumented, and — the part that actually matters — metrics that meant something rather than vanity numbers that look busy and tell you nothing. Then alert thresholds set on those, surfaced where the team would actually see them and could act while there was still time to act.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Problems started getting caught and dealt with before they escalated, and system reliability improved for it. The team shifted from reactive firefighting to something calmer and more proactive — catching issues while they were still small enough to be boring.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/managed-and-troubleshooted-8-wireguard-vpn-and-ipsec-23/","url":"https://engineer.company/portfolio/managed-and-troubleshooted-8-wireguard-vpn-and-ipsec-23/","title":"Managed and troubleshooted 8 WireGuard VPN and IPSEC VPN connections, ensuring secure communication across Google Cloud and Linux systems.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Secure connectivity between the cloud and the on‑premises Linux systems ran over several VPN tunnels, and they were fragile and awkward to diagnose when they dropped. A dead tunnel could cut communication between environments, and troubleshooting one was slow and uncertain — you were never quite sure you\u0026rsquo;d found the real cause.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Managing and troubleshooting those connections, to guarantee secure and uninterrupted communication, was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The VPN estate came under control — eight WireGuard and IPSec tunnels across Google Cloud and the Linux systems, managed and troubleshot as a set rather than eight separate mysteries. Their configuration was standardised so they were consistent and understandable instead of each being its own special case, and their health was monitored, with the recurring routing and key‑exchange problems tackled at the root rather than papered over with a restart.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e All eight tunnels ran securely and reliably, communication between environments stayed protected, and the recurring connectivity incidents that used to interrupt work stopped happening. Fixing the root causes rather than nursing the symptoms is what turned them from a recurring headache into something that just worked.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/led-the-software-development-of-a-gis-map-24/","url":"https://engineer.company/portfolio/led-the-software-development-of-a-gis-map-24/","title":"Led the software development of a GIS map application, driving revenue growth by 10x and positioning the product as a primary data asset.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The core challenge was to build a platform that could track, monitor, and optimize renewable energy assets like solar panels and wind turbines. However, the initial solution lacked robust geospatial capabilities, making it difficult for clients to visualize asset locations, analyze spatial data, or derive actionable insights. Recognizing this gap, the leadership team prioritized developing a GIS (Geographic Information System) map application to enhance the platform’s value and meet evolving customer needs.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to lead the development of the GIS application, a critical component to differentiate the product in the competitive green energy market. The role extended beyond software development — spanning tech leader, devops engineer, data engineer, and SRE (Site Reliability Engineer), ensuring the solution aligned with the company’s growth trajectory. The goal was to create a scalable, intuitive GIS tool that integrated seamlessly with the SaaS platform, enabling users to visualize asset locations, track performance metrics, and leverage spatial data for decision‑making. This required balancing technical innovation with the constraints of a growing startup, while ensuring the product could evolve alongside the company.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e It began with collaborating with stakeholders to define the GIS application’s core functionalities, focusing on integration with the existing SaaS platform and real‑time data visualization. Given the small team size, a modular architecture was designed using open‑source GIS libraries to keep the system lightweight and scalable. CI/CD pipelines, automated infrastructure provisioning, and monitoring tools were also implemented to ensure reliability. As the team expanded, new engineers were mentored, cross‑functional collaboration facilitated, and user feedback prioritized to refine the application iteratively. Over time, the GIS tool evolved from a basic prototype into a sophisticated platform, incorporating advanced analytics and custom dashboards to meet customer demands.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The GIS application became a cornerstone of the SaaS platform, driving a 10x increase in revenue through upsells, data licensing, and new customer acquisitions. Its ability to visualize green energy assets in real time improved operational efficiency for clients, while the tool’s continuous refinement positioned it as a primary data asset. The success of the project not only solidified the company’s reputation in the renewable energy sector but also demonstrated the value of a multi‑disciplinary approach in a fast‑paced startup environment. By combining technical expertise with strategic vision, the GIS application became a key differentiator, fueling long‑term growth and innovation.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/directed-full-stack-gis-map-development-overseeing-postgresql-25/","url":"https://engineer.company/portfolio/directed-full-stack-gis-map-development-overseeing-postgresql-25/","title":"Directed full‑stack GIS map development, overseeing PostgreSQL, Mapbox, ReactJS, and NodeJS to deliver an integrated solution.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e By this stage the GIS map had stopped being a feature and become the reason customers logged in. The trouble was that it had grown up in pieces. Spatial data lived in PostgreSQL, the map itself was drawn with Mapbox, and the application around it was ReactJS on the front with NodeJS behind. Each part worked on its own. They just hadn\u0026rsquo;t been built to fit together, and the seams were starting to show.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The role covered the full‑stack development of the map and the technical direction that came with it: the data model, the rendering, the API and the React front end. The goal was to turn four things that happened to share a repository into one product worth standing behind.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The architecture was set first, then the work stayed close to the code rather than steering from a distance. On the data side, the PostgreSQL spatial model was kept tidy so queries didn\u0026rsquo;t slow to a crawl as the datasets grew. Mapbox did the drawing; the job was feeding it the right data at the right zoom levels instead of everything at once. On the application side, the ReactJS and NodeJS work got reviewed, the team was pushed toward shared conventions, and responsibilities kept getting moved back to the layer they belonged in whenever one started leaking into the next. A fair amount of it was unglamorous work: catching the small inconsistencies before they hardened into architecture.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e What came out was a single integrated map application, with data, rendering and interface finally pulling the same way. It became a core part of the platform, and something the team could keep extending without it buckling every time a layer got added.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/saved-4-000-hours-by-mentoring-and-growing-26/","url":"https://engineer.company/portfolio/saved-4-000-hours-by-mentoring-and-growing-26/","title":"Saved 4,000 hours by mentoring and growing a team from 2 to 18 members, optimizing workflows and fostering cross‑departmental collaboration.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A team of two couldn\u0026rsquo;t keep up anymore. The product was pulling in more work than a pair could deliver, and the way the work happened — knowledge in people\u0026rsquo;s heads, no real conventions — wasn\u0026rsquo;t going to survive being scaled up. Adding bodies to a team that loose usually just makes the chaos bigger.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to grow the team and, at the same time, build the structure that would let a bigger group move faster instead of slower. Mentoring the new people was half of it. Fixing the workflows so nobody stalled waiting on someone else was the other half.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The team grew from 2 to 18 over time, with the hiring and the mentoring treated as the same job: everyone who joined needed to be able to work unsupervised. Shared standards meant code and process looked the same regardless of who wrote them, and real effort went into the handovers between specialities, because that is where teams quietly lose their days. When something kept tripping people up, the fix went to the process rather than the symptom.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The bigger, better‑mentored team, running on workflows that had actually been designed, saved on the order of 4,000 hours. But the number isn\u0026rsquo;t really the point. What got built was durable engineering capability — a group that could carry the work with or without any one person in the room.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/optimized-forecasting-and-investment-strategies-for-11-electricity-27/","url":"https://engineer.company/portfolio/optimized-forecasting-and-investment-strategies-for-11-electricity-27/","title":"Optimized forecasting and investment strategies for 11 electricity grid operators, driving operational efficiency through data‑driven GIS solutions.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Electricity grid operators live and die on decisions about where to reinforce the network and where to put their money, and eleven of them were making those calls without much geospatial analysis underneath. They had the operational data. What they didn\u0026rsquo;t have was a way to see it on the map, where the patterns actually live.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The job was to sharpen their forecasting and their investment strategies with GIS — to turn tables of readings into something that showed them where capacity was getting tight, where risk was building, and where the next pound was best spent.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Their operational data was brought together with geospatial modelling so the two reinforced each other. Instead of forecasting in the abstract, the grid could be looked at spatially and asked concrete questions: which stretches were heading toward their limits, which areas justified investment first. For eleven operators that meant fitting the analysis to how each of them actually ran their network, not handing everyone the same template and hoping it fit.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The operators came away with forecasts they could trust and investment decisions that were aimed rather than hopeful. Grounding the planning in what the map showed made the whole thing more efficient — money and attention went where the data pointed instead of where habit did.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/presented-200-ui-ux-improvements-for-the-gis-28/","url":"https://engineer.company/portfolio/presented-200-ui-ux-improvements-for-the-gis-28/","title":"Presented 200 UI/UX improvements for the GIS map application, boosting revenue by 10x through enhanced software features.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The map interface had grown powerful and, along the way, complicated. There were places where you could feel customers not getting the value that was sitting right there in front of them — good functionality trapped behind clumsy interactions. That gap between what the product could do and what people found easy to do was quietly costing us.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The job was finding those gaps and pushing the fixes through: the usability work that would make the product easier to get value from and, not by coincidence, more valuable commercially.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Rather than guess at what was wrong, the work went into the feedback and the usage data, and out of that came a backlog of 200 concrete UI/UX improvements. They weren\u0026rsquo;t treated as equal — ranked by impact, with the ones that mattered argued for and taken through the team to ship as real features instead of a wishlist that sat in a document going stale.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The interface got noticeably better to use, and the product\u0026rsquo;s value followed: the work contributed to a tenfold rise in revenue. It\u0026rsquo;s a case worth coming back to, because it makes the point cleanly — careful UX isn\u0026rsquo;t cosmetic, it shows up on the invoice.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-and-managed-5-000-hours-of-map-29/","url":"https://engineer.company/portfolio/designed-and-managed-5-000-hours-of-map-29/","title":"Designed and managed 5,000 hours of map development, utilizing Agile methodologies such as Scrum and Jira for effective project management.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The map wasn\u0026rsquo;t built in a sprint. It was thousands of hours of work spread across a lot of people and a lot of months, and that kind of effort drifts if nobody is holding the line on scope and schedule. Left alone, it quietly becomes late.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The responsibility was designing and running the development effort so it delivered on purpose rather than by luck — keeping the priorities honest and the progress visible to anyone who wanted to look.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e It ran on Agile: proper Scrum, with the ceremonies actually used rather than performed, and the work tracked in Jira so people could see where things stood without having to ask. Somewhere around 5,000 hours of map development went through that process. The emphasis was less about ceremony for its own sake and more about keeping priorities pointed at what mattered and catching drift early, while it was still cheap to fix.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The 5,000 hours landed in a controlled, visible way instead of disappearing into a black box. The project management did what it\u0026rsquo;s meant to do — and what mostly goes unnoticed when it works: it kept the work aligned to the goals and roughly on the timeline, without heroics at the end.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/wrote-50-000-words-of-comprehensive-software-documentation-30/","url":"https://engineer.company/portfolio/wrote-50-000-words-of-comprehensive-software-documentation-30/","title":"Wrote 50,000 words of comprehensive software documentation utilizing Markdown in GitHub, Craft, and Confluence, thereby ensuring the retention of knowledge and the transparency of the process.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Most of what mattered about the product and how the team worked lived in people\u0026rsquo;s heads. That\u0026rsquo;s fine right up until someone new joins, or someone leaves — and then onboarding crawls and a chunk of institutional memory is one resignation away from being gone for good.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to get that knowledge out of heads and into documentation people would actually keep and use: clear enough to be read, structured enough to be maintained rather than abandoned after a month.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Much of it was written by hand, around 50,000 words by the end, in Markdown across GitHub, Craft and Confluence depending on where each piece belonged. It covered the architecture, the processes and the practical how‑to material — the questions people kept asking. It was kept version‑controlled and, just as importantly, findable, because documentation nobody can locate might as well not exist.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The knowledge stopped being fragile. New people got up to speed faster, the process became something you could point at instead of reconstruct from memory, and the whole thing turned auditable: you could see how and why work was done rather than take it on trust.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/gathered-and-analyzed-business-requirements-to-translate-into-31/","url":"https://engineer.company/portfolio/gathered-and-analyzed-business-requirements-to-translate-into-31/","title":"Gathered and analyzed business requirements to translate into actionable features and user stories aligned with data governance standards.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Requirements tended to arrive as conversations — someone wanted something, roughly, and it fell to the developers to guess at the edges. Guessing means rework, and rework is about the most expensive way there is to build anything.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The role sat between the business and the engineering, translating one into the other: turning loose needs into work a developer could pick up without guessing, and keeping it lined up with the data‑governance standards along the way.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The requirements got worked out with the stakeholders directly, with the awkward questions asked early instead of discovered late, then written up as features and user stories that actually said what \u0026ldquo;done\u0026rdquo; meant. Each one was checked against the governance rules, because a feature that\u0026rsquo;s useful but mishandles data isn\u0026rsquo;t really finished. The whole aim was that someone could read a story and build the right thing the first time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Development ran off clear, agreed features instead of half‑understood asks. Ambiguity fell, and rework fell with it, and the delivery stayed pointed at the actual business goals — inside the data‑governance lines rather than tidied up to fit them afterward.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/managed-the-execution-of-30-successful-gis-projects-32/","url":"https://engineer.company/portfolio/managed-the-execution-of-30-successful-gis-projects-32/","title":"Managed the execution of 30 successful GIS projects, demonstrating leadership in delivering innovative solutions across the field.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Mappitall made its money delivering GIS projects, and there were a lot of them running at once. The company\u0026rsquo;s growth rode on getting them out the door reliably — not one flagship project done brilliantly, but a steady stream of them landing on time and holding together, which only happens when the coordination across the team is actually working.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The responsibility was getting that portfolio delivered — keeping scope, people and timelines lined up across all of it, and giving the team the direction to ship.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Across those years, the delivery of thirty GIS projects ran through this role. In practice that meant holding the scope steady when it wanted to creep, pointing the right people at the right work, and staying close enough to each project to catch trouble while it was still small. When something was going to slip, better to know early and reshuffle than find out at the deadline. A lot of the job was just keeping the plates spinning and the client\u0026rsquo;s expectations honest about what was coming and when.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e All thirty came in. That consistency mattered more than any single project would have — a client who\u0026rsquo;s seen you deliver thirty times over doesn\u0026rsquo;t worry about the thirty‑first, and that reputation is a good part of why the company kept growing.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/led-company-growth-from-4-to-14-employees-33/","url":"https://engineer.company/portfolio/led-company-growth-from-4-to-14-employees-33/","title":"Led company growth from 4 to 14 employees by employing Agile methodologies and effective project management practices.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Mappitall was ready to grow, and there\u0026rsquo;s a specific danger in that moment: you add people faster than you add process, and both the quality and the shared sense of how things are done start to fray. Four people who all know what everyone else is doing is a very different thing from fourteen who don\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Leading that growth was the job — bringing people in while keeping delivery disciplined and the team pulling in the same direction.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The company went from four people to fourteen. That was hiring and onboarding done deliberately rather than in a panic, but the bigger piece was putting in the ways of working that let a team that size not trip over itself — Agile practices, real project management, the habits that keep everyone\u0026rsquo;s work visible to everyone else. The tenth and fourteenth hires needed to walk into something that already had a shape, not to have to guess at how things were done.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The team got to fourteen without the quality dropping or splintering into people who didn\u0026rsquo;t know what the others were up to. The Agile side of it is what kept a bigger group productive — the process grew with the headcount instead of lagging behind it.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/improved-team-communication-and-collaboration-by-implementing-slack-34/","url":"https://engineer.company/portfolio/improved-team-communication-and-collaboration-by-implementing-slack-34/","title":"Improved team communication and collaboration by implementing Slack, Mattermost, 1Password, and Jira, saving 8,000 hours of labor.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e As the team got bigger, the communication and the tooling hadn\u0026rsquo;t kept up, and it showed. Things got said in one place and missed by the people who needed them, work got duplicated because nobody could see what someone else had already done, and coordinating anything took longer than the work itself. That kind of friction is invisible day to day, but it adds up to a lot of lost time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to fix how the team communicated and worked together, and claw back the time being quietly bled to all that friction.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The tools got brought in and standardised, and — this is the part that actually matters — the practices for using them were set so they didn\u0026rsquo;t just become another place to check. Slack and Mattermost for communication, 1Password so shared secrets weren\u0026rsquo;t being passed around in ways nobody could track, Jira so work was tracked in one place instead of living in people\u0026rsquo;s heads and inboxes. The tools were the easy bit; getting everyone to actually use them the same way was the real work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Communication and collaboration got noticeably better, and the streamlined setup saved something on the order of 8,000 hours of labour — time that had been going into chasing information and redoing work, now going into actual delivery.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/led-the-development-deployment-and-support-of-over-35/","url":"https://engineer.company/portfolio/led-the-development-deployment-and-support-of-over-35/","title":"Led the development, deployment, and support of over 30 GIS projects, demonstrating expertise in PostgreSQL, Bash, Python, JavaScript, GDAL, ArcGIS, PostGIS, and Mapbox technologies.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The company\u0026rsquo;s whole output was made‑to‑measure GIS — custom mapping and spatial systems built to a client\u0026rsquo;s specific problem, then kept running once they were live. Building the thing is only half of it; a geospatial project that ships and then falls over in production hasn\u0026rsquo;t really been delivered.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e These projects ran end to end through this role — the development, the deployment, and the support once they were live — with the technical direction across a fairly wide stack.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Delivery ran on more than thirty GIS projects, hands‑on across the stack the whole way. PostgreSQL with PostGIS underneath for the spatial data, GDAL/OGR for moving it between formats — shapefiles, GeoJSON, GeoTIFF, KML, vector tiles — and QGIS and JOSM for the data work itself. On the front of it, web maps built on Mapbox GL and Leaflet, sometimes against the ArcGIS or HERE APIs, with the app layer in JavaScript, Python, PHP and SQL. The work ranged from 2D and 3D digital mapping through LiDAR processing, georectification and vectorisation to indoor mapping and navigation. And the responsibility ran past the point of shipping — the deployment and the ongoing support in production were part of it too, so problems weren\u0026rsquo;t handed off; the decisions had to be lived with.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Thirty‑plus projects built, deployed and supported across that whole range. Being on the hook for the full lifecycle rather than just the build is what kept the quality honest — you design differently when you know you\u0026rsquo;re the one getting the call if it breaks.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/contributed-to-user-interface-design-processes-ensuring-intuitive-36/","url":"https://engineer.company/portfolio/contributed-to-user-interface-design-processes-ensuring-intuitive-36/","title":"Contributed to user interface design processes, ensuring intuitive, visually appealing, and user‑friendly project interfaces.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The interfaces across our projects were uneven. Some were fine, some had clearly been built by engineers thinking about the data model rather than the person who\u0026rsquo;d have to use it, and the design decisions weren\u0026rsquo;t always made with the end user in the room. On a web‑map product especially, the map is the easy part — it\u0026rsquo;s the controls, the filtering and the flow around it where people get lost.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Getting involved in the UI design process was part of the role — to help make the interfaces something people actually found intuitive and pleasant to use, not just functional.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The role wasn\u0026rsquo;t the designer\u0026rsquo;s, but it sat in the design process and brought an engineering perspective — pushing on layout, on the flow through a task, on whether a screen was actually clear or just familiar to the people who\u0026rsquo;d built it. These were React, Angular and Vue front‑ends sitting over Mapbox and Leaflet maps, and a lot of the usability lived in the details: how you filtered a dataset, how you moved between floors on an indoor map, whether the thing told you what it was doing. Mostly it meant asking the dumb‑user questions early, while they were still cheap to fix, instead of after release when the confusion came back as support tickets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The interfaces got more intuitive and more polished, which end users felt directly, and it lifted the overall quality of what got put out. Getting the usability questions asked during design rather than after release is most of what made the difference.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/guided-the-execution-of-numerous-company-projects-offering-37/","url":"https://engineer.company/portfolio/guided-the-execution-of-numerous-company-projects-offering-37/","title":"Guided the execution of numerous company projects, offering expert support in the software development phases.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e There were a lot of projects running at the same time, each in the middle of its development phase, and they all needed steady technical guidance to stay on the rails. Left alone, projects drift — a wrong approach taken early gets expensive by the time anyone notices.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Guiding that execution was the job — being the technical support the teams could lean on through the development phases.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The work stayed hands‑on across a lot of the company\u0026rsquo;s projects at once. That meant unblocking people when they were stuck, looking hard at an approach before too much got built on top of it, and generally staying close enough to catch a project heading the wrong way while it was still a course correction and not a rebuild. The idea was to be available rather than a gate — to keep things moving, not to make everything wait on one person.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Projects moved through their tricky development stages more smoothly with someone experienced to lean on at the right moments, and that steadied delivery right across the company\u0026rsquo;s portfolio.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/overhauled-internal-processes-saving-8-000-hours-by-38/","url":"https://engineer.company/portfolio/overhauled-internal-processes-saving-8-000-hours-by-38/","title":"Overhauled internal processes, saving 8,000 hours by improving software architecture, systems, and scheduling efficiency.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The way things were done internally had accumulated the usual cruft — software architecture that had grown by accretion rather than design, systems that worked but not efficiently, scheduling that left people either waiting or slammed. None of it was on fire, which is exactly why it had been left alone, but it was quietly costing a lot of time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to overhaul those processes — to go find the waste and take it out rather than keep paying for it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The internal processes got reworked across three fronts: the software architecture, so it was something you could reason about and build on instead of work around; the systems, streamlined so the routine work stopped taking longer than it should; and the scheduling, so capacity was actually matched to the work. And the changes were made to stick — embedded in how the team operated rather than left as a memo everyone nodded at and forgot — because process improvements that aren\u0026rsquo;t made permanent just decay back to the old way.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The overhaul saved roughly 8,000 hours by making the architecture, systems and scheduling meaningfully more efficient. That\u0026rsquo;s capacity that went straight back into higher‑value work instead of into overhead nobody had thought to question.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/administered-network-infrastructure-for-over-1-000-servers-39/","url":"https://engineer.company/portfolio/administered-network-infrastructure-for-over-1-000-servers-39/","title":"Administered network infrastructure for over 1,000 servers, ensuring optimal system deployment, security, and troubleshooting.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The company\u0026rsquo;s operations sat on top of a big server estate — over a thousand of them — and an estate that size doesn\u0026rsquo;t stay reliable on its own. Deployment, security and the steady stream of things that go wrong all need someone running them with actual discipline, or the whole thing gets flaky and nobody\u0026rsquo;s quite sure why.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Administering that network infrastructure was the job — keeping it secure, keeping it reliable, keeping it consistent at a scale where inconsistency is what kills you.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The network infrastructure ran across more than a thousand servers. How systems got deployed was standardised, so a server came up the same predictable way instead of each one being a little bit bespoke; the security was hardened rather than trusting that nobody would come looking; and the troubleshooting got handled when something did break. At that scale the standardisation is what saves you — a thousand snowflakes is unmanageable, a thousand of the same thing is just work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The estate ran with reliable deployment, solid security and problems that got dealt with promptly instead of festering. That\u0026rsquo;s the kind of infrastructure work that\u0026rsquo;s invisible when it\u0026rsquo;s going well, which is the point — it was the stable backbone everything else at the company ran on.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/established-a-technical-support-department-servicing-over-10-40/","url":"https://engineer.company/portfolio/established-a-technical-support-department-servicing-over-10-40/","title":"Established a Technical Support department, servicing over 10,000 clients with IT support and troubleshooting solutions.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The client base was growing and needed dependable technical support, and there just wasn\u0026rsquo;t a dedicated function to give it to them at any real scale. Support was happening ad hoc, which works for a handful of clients and quietly falls apart as the numbers climb.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Standing up an actual technical‑support capability — one that could serve a large and still‑growing client base — was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A Technical Support department got built from nothing. That meant deciding how it would actually work before hiring into it — the process for how a request came in and got resolved, the tooling to handle volume, the standard for what good support looked like — and then building the capacity to deliver IT support and troubleshooting to a lot of clients at once. Starting from scratch was the advantage, honestly; it could be designed for the scale the company was heading toward instead of patching something that had grown up by accident.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The department ended up serving over ten thousand clients with reliable support and troubleshooting. Support went from a thing done reactively to a genuine strength of the company — something that scaled with the client base instead of buckling under it.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/automated-ssl-tls-certificate-creation-for-100-docker-41/","url":"https://engineer.company/portfolio/automated-ssl-tls-certificate-creation-for-100-docker-41/","title":"Automated SSL/TLS certificate creation for 100 Docker applications, ensuring secure connections across Ubuntu Linux hosts.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A hundred Docker applications all needed SSL/TLS certificates, and certificates are the kind of thing that\u0026rsquo;s fine right up until they aren\u0026rsquo;t. Issuing and renewing a hundred of them by hand is slow, it\u0026rsquo;s dull, and it\u0026rsquo;s exactly the sort of manual job where one forgotten renewal takes an app down with an expiry error at the worst possible moment.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The goal was certificate creation and renewal automated — every app with valid, trusted encryption, and nobody having to remember to do anything.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e An ACME‑based workflow handled the whole lifecycle for the hundred Docker applications — creating the certificates and renewing them before they lapsed — and deployed them automatically across the Ubuntu Linux hosts, which were running a mix of Apache and Nginx. The whole aim was to take the human out of it, because the human is the part that forgets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e All hundred applications kept valid certificates and secure connections on their own. The manual certificate work just disappeared, and with it the whole category of outage where something breaks not because it failed but because a cert quietly expired and nobody noticed.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/streamlined-ci-cd-processes-saving-4-000-hours-42/","url":"https://engineer.company/portfolio/streamlined-ci-cd-processes-saving-4-000-hours-42/","title":"Streamlined CI/CD processes, saving 4,000 hours by introducing automation in software development pipelines.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Getting software out the door relied on manual, inconsistent steps — someone remembering the sequence, doing it slightly differently each time — and it slowed releases down and ate engineering hours that should have gone into building things.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to streamline the CI/CD process and get automation into the pipelines, so releases stopped being a manual ritual.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Automated build, test and deployment pipelines went in, so the path from a change to it running in production was standardised instead of improvised. The repetitive manual steps — the ones that were slow and, worse, done differently depending on who was doing them — came out. Once the pipeline is doing it the same way every time, a whole class of \u0026ldquo;it worked on my machine\u0026rdquo; and half‑remembered deploy steps just stops happening.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The automation gave back roughly 4,000 hours and made releases both faster and more reliable. The team could ship without bracing for it — the confidence came from the process being consistent, not from everyone being careful.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/streamlined-data-analysis-and-software-development-processes-saving-43/","url":"https://engineer.company/portfolio/streamlined-data-analysis-and-software-development-processes-saving-43/","title":"Streamlined data analysis and software development processes, saving 4,000 hours by introducing GitHub, GitLab, Bash, and Python CI/CD practices.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Both the data‑analysis work and the software development were being held back by the same thing: manual processes. Work moved from development to delivery in a slow, inconsistent way, and the analysis side had its own pile of repetitive steps someone was doing by hand every time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to streamline both by bringing modern automation and CI/CD practices to workflows that hadn\u0026rsquo;t had them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e CI/CD practices went in, built on GitHub and GitLab, with Bash and Python doing the automation work underneath. The repetitive steps across both the data‑analysis and the development workflows got automated, and how work moved from development through to delivery got standardised so it was the same every time rather than reinvented per project. Bringing the analysis side into the same disciplined pipeline as the dev work was a big part of it — it had been treated as a separate, more manual world.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The streamlined processes saved roughly 4,000 hours and sped up both the data analysis and the software development, and just as usefully made what got shipped more consistent — fewer surprises from work that had been done a slightly different way each time.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/developed-a-data-analytics-reporting-system-increasing-quarterly-44/","url":"https://engineer.company/portfolio/developed-a-data-analytics-reporting-system-increasing-quarterly-44/","title":"Developed a Data Analytics reporting system, increasing quarterly software revenue by 400% through Python‑based PDF reports.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Stakeholders weren\u0026rsquo;t getting analytics in any timely, readable form. The data existed, but turning it into something you could actually make a decision from was slow and manual, so visibility into how things were performing lagged, and the commercial decisions lagged with it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Building a data‑analytics reporting system — one that turned raw data into clear, regular insight without someone hand‑assembling it each time — was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A reporting system generated PDF reports in Python, automating the whole chain: pulling the data, running the analysis, and presenting it in a clean, consistent format stakeholders could actually read. The point was regularity and clarity — the same professional report landing predictably, so the numbers became something people looked at as a matter of course rather than something they had to go and dig for.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e That reporting is what drove quarterly software revenue up by 400%. Making the analytics better and faster wasn\u0026rsquo;t a back‑office nicety — put clear, timely numbers in front of the people making commercial decisions and the decisions get better, and here that showed up directly on the revenue.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/automated-data-processing-tasks-using-shell-scripting-pl-45/","url":"https://engineer.company/portfolio/automated-data-processing-tasks-using-shell-scripting-pl-45/","title":"Automated data processing tasks using Shell scripting, PL/pgSQL, Python, and Transact‑SQL, increasing productivity and efficiency.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e There was a steady load of recurring data‑processing work being done by hand. Manual data work has two problems at once: it eats time, and it\u0026rsquo;s inconsistent — do the same task by hand enough times and it\u0026rsquo;ll get done slightly differently, and some of those differences are errors.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to automate these tasks, both to get the time back and to make them reliable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The data‑processing work got automated across the databases and systems it touched, using whatever fit the job — Shell scripting for the glue, PL/pgSQL and Transact‑SQL down in the databases, Python where it needed more than SQL could give. Manual steps got replaced with jobs that ran the same way every time, which is the whole point: a script doesn\u0026rsquo;t get bored, doesn\u0026rsquo;t skip a step, and doesn\u0026rsquo;t do it differently on a Friday afternoon.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Productivity and efficiency both went up, the manual effort came off people\u0026rsquo;s plates, and the data processing became consistent and dependable instead of a source of small, recurring errors.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/enhanced-project-efficiency-saving-150-hours-per-month-46/","url":"https://engineer.company/portfolio/enhanced-project-efficiency-saving-150-hours-per-month-46/","title":"Enhanced project efficiency, saving 150 hours per month across 30 projects by optimizing workflows and resource management.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Across a portfolio of around thirty projects, time was being lost every single month to workflows that had never been optimised and resource management that was uneven — some people underused, some overloaded, work planned differently from one project to the next.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The aim was to make the portfolio more efficient and recover the time that was going missing month after month.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Going through the thirty projects, the workflows and the resource management got worked on together — taking out the bottlenecks, balancing the workloads so the same few people weren\u0026rsquo;t always the constraint, and standardising how work got planned and run so each project wasn\u0026rsquo;t its own special case. Thirty projects each losing a bit of time adds up; the fix was mostly about making the good practices consistent rather than inventing anything clever.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The changes saved around 150 hours a month across the portfolio. That\u0026rsquo;s a recurring monthly saving, not a one‑off — thirty projects running leaner, month in and month out.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/managed-a-team-delivering-it-support-data-recovery-47/","url":"https://engineer.company/portfolio/managed-a-team-delivering-it-support-data-recovery-47/","title":"Managed a team delivering IT support, data recovery, and hardware repair services to over 1,000 clients, ensuring high‑quality service.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The company was the place a large base of clients came to when their IT broke — support, data recovery, hardware repair, the full spread. Meeting that kind of steady, unglamorous demand isn\u0026rsquo;t about heroics; it\u0026rsquo;s about having a team that runs well day after day, because the work never really stops coming.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Managing the team that delivered all that was the job, and keeping the quality consistent whether it was a quiet week or everything arriving at once.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The team ran IT support, data recovery and hardware repair for over a thousand clients. A lot of that was the organising underneath — making sure work got picked up and not dropped, setting a standard for what \u0026ldquo;fixed\u0026rdquo; actually meant so people weren\u0026rsquo;t getting half‑repairs back, and keeping the team effective when the queue was long. Data recovery especially is work you can\u0026rsquo;t be casual about; it\u0026rsquo;s usually someone\u0026rsquo;s photos or their business sitting on that drive, and they\u0026rsquo;re already having a bad day by the time they reach you.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The team served over a thousand clients and built a real reputation for reliable service. In that kind of business the reputation is everything — people come back, and they tell others, precisely because the last time something broke you actually sorted it.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/configured-and-deployed-1-000-wi-fi-routers-48/","url":"https://engineer.company/portfolio/configured-and-deployed-1-000-wi-fi-routers-48/","title":"Configured and deployed 1,000 Wi‑Fi routers, improving network accessibility and performance for clients.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Clients needed wireless that just worked, and that came down to configuring and rolling out a large number of Wi‑Fi routers — and doing it the same careful way every time, because a router set up sloppily is either insecure or slow, and usually you find out which one later.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Configuring and deploying those routers to give clients better network access and performance was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A thousand Wi‑Fi routers got configured and deployed. The trick at that number is standardising the setup — a consistent, secure, sensible configuration — rather than tuning each one from scratch on the day, because a thousand hand‑crafted routers is a thousand different things to support later. So they were set up for security and performance the same way each time, and rolled out reliably across client sites.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The thousand routers gave clients dependable wireless — better access, better performance — and did it consistently, because the setup was standard rather than improvised. A router nobody has to think about again is the goal; most of these got there.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/managed-4-000-computer-repairs-ensuring-rapid-and-49/","url":"https://engineer.company/portfolio/managed-4-000-computer-repairs-ensuring-rapid-and-49/","title":"Managed 4,000 computer repairs, ensuring rapid and effective resolution of hardware and software issues.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e There was a constant stream of computer repairs coming through — four thousand of them over time — and every one was someone waiting to get their machine back and get on with their day. Hardware faults, software faults, the whole mix, and clients judged the shop on how fast and how properly they got fixed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Managing those repairs was the job — keeping problems getting resolved quickly and, just as importantly, correctly.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Four thousand computer repairs went through — diagnosing the hardware and software faults, organising the workflow so machines moved through instead of piling up, and holding the quality so a repair was actually done right rather than sent back out to fail again next week. A repair that comes back is worse than a slow one; it costs the client a second trip and costs the shop the trust. So the throughput mattered, but never at the expense of fixing it the first time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e All four thousand got resolved, and quickly. People got their machines back working and got on with things, and the company\u0026rsquo;s name for dependable service held up — which in a repair shop is the whole business.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/administered-100-bare-bone-servers-physical-networks-and-50/","url":"https://engineer.company/portfolio/administered-100-bare-bone-servers-physical-networks-and-50/","title":"Administered 100 Bare Bone servers, physical networks, and IP telephony systems, ensuring robust infrastructure for company growth.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Underneath everything the company did was the physical stuff — servers, the actual networks, the IP‑telephony — and it all had to just run. That layer is invisible when it works and extremely visible the moment it doesn\u0026rsquo;t, and the company\u0026rsquo;s growth was resting on it staying dependable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Administering that infrastructure and keeping it stable as the company grew was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A hundred bare‑bone servers, along with the physical networks and the IP‑telephony systems, were looked after — the setup, the maintenance, the troubleshooting when something went wrong. Bare‑bone servers mean dealing with the hardware directly, so there\u0026rsquo;s a hands‑on, physical side to it: the cabling, the boxes, the phone system that everyone notices the second a call drops. The job was to keep all of it boring, in the good sense.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The servers, the networks and the telephony ran reliably, and that dependable physical foundation is what let the company keep growing without the ground shifting underneath it.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/developed-100-web-applications-using-html-html5-css-51/","url":"https://engineer.company/portfolio/developed-100-web-applications-using-html-html5-css-51/","title":"Developed 100 web applications using HTML/HTML5, CSS/SCSS, Django, WordPress, and Joomla frameworks, ensuring diverse online presence.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Clients wanted web applications, and they wanted very different things — different scales, different budgets, different levels of \u0026ldquo;just get me online\u0026rdquo; versus \u0026ldquo;build me something custom.\u0026rdquo; Meeting that meant being versatile rather than forcing every client down the same technology.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Building web applications that gave each client a diverse, effective online presence was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A hundred web applications got built, and the point was matching the tool to the job rather than having a favourite. Where a client needed something custom, that was HTML/HTML5, CSS/SCSS and Django; where they needed something more standard that they could also manage themselves, WordPress or Joomla was the faster, more sensible answer. Part of the skill was knowing which was which — talking a client out of a bespoke build they didn\u0026rsquo;t need, or into one they did.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The hundred applications gave clients a varied, capable online presence, each delivered on the technology that actually fit it. Matching the approach to the client rather than the other way round is what made them effective rather than just delivered.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-30-websites-delivering-unique-and-flexible-solutions-52/","url":"https://engineer.company/portfolio/designed-30-websites-delivering-unique-and-flexible-solutions-52/","title":"Designed 30 websites, delivering unique and flexible solutions by converting Photoshop designs to HTML.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Clients came in with a look they wanted — often a finished visual design — and needed a website built faithfully from it. The gap between a design file and a working site is where a lot of quality is won or lost: it\u0026rsquo;s easy to ship something that\u0026rsquo;s roughly right and subtly wrong.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Designing the sites and converting the designs into accurate, flexible implementations was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Thirty websites got designed and the Photoshop designs converted into HTML by hand. Faithful was the standard — the spacing, the type, the details the designer actually intended, not an approximation of them — but so was flexible, because a site that matches the mockup pixel‑for‑pixel and then falls apart the moment the content changes hasn\u0026rsquo;t really been built well. So the aim was markup that stayed true to the design and stayed maintainable afterwards.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The thirty sites matched their designs and stayed workable — distinctive, polished web presences that didn\u0026rsquo;t break the first time someone edited them. Faithful to the design and still maintainable is the balance that mattered, and that\u0026rsquo;s where these landed.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/administered-40-websites-on-ubuntu-linux-hosting-servers-53/","url":"https://engineer.company/portfolio/administered-40-websites-on-ubuntu-linux-hosting-servers-53/","title":"Administered 40 websites on Ubuntu Linux hosting servers with Apache and Nginx, ensuring high availability and performance.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e There was a portfolio of live websites that needed to stay up and stay fast — and hosting is another of those jobs that\u0026rsquo;s invisible until a site goes down, at which point it\u0026rsquo;s the only thing anyone cares about.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Administering those sites and keeping them highly available and quick was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Forty websites ran on Ubuntu Linux hosting servers, on a mix of Apache and Nginx — the configuration, the performance tuning, the ongoing maintenance to keep them reliable under real traffic. Real traffic is the operative bit: a site that\u0026rsquo;s fine when nobody\u0026rsquo;s using it and falls over when they are hasn\u0026rsquo;t been administered, it\u0026rsquo;s just been left alone. So the work was keeping them healthy under actual load.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e All forty ran with high availability and good performance, which gave clients hosting they didn\u0026rsquo;t have to think about. Stable and dependable under real use is the entire point of hosting, and that\u0026rsquo;s what these delivered.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/engineered-600-pl-pgsql-based-etl-elt-pipelines-54/","url":"https://engineer.company/portfolio/engineered-600-pl-pgsql-based-etl-elt-pipelines-54/","title":"Engineered 600 PL/pgSQL‑based ETL/ELT pipelines to streamline complex data processing workflows across multiple PostgreSQL development and production environments.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The organization was managing large volumes of transactional and analytical data across multiple PostgreSQL development and production environments. The existing data pipelines were fragmented, lacked consistency, and were causing performance bottlenecks, leading to delays in business‑critical reporting and decision‑making.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to design and implement robust, scalable, and efficient ETL/ELT pipelines using PL/pgSQL to streamline complex data ingestion, transformation, and loading workflows. A key objective was to improve query performance and ensure data integrity across all environments.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Over 600 PL/pgSQL‑based ETL/ELT pipelines were engineered to automate the extraction, transformation, and loading of data from various sources. Key technical implementations included:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eLeveraged partitioned tables and materialized views to optimize read performance for large datasets.\u003c/li\u003e\n\u003cli\u003eApplied primary and foreign key constraints to maintain referential integrity during transformations.\u003c/li\u003e\n\u003cli\u003eDesigned unique and composite indexes to speed up JOIN operations and complex filtering criteria.\u003c/li\u003e\n\u003cli\u003eIncorporated exception handling and transactional control to ensure fault tolerance and rollback in case of failures.\u003c/li\u003e\n\u003cli\u003eEnabled incremental loads using change data capture (CDC) mechanisms and timestamp‑based deltas, reducing processing time by over 60%.\u003c/li\u003e\n\u003cli\u003eDeveloped automated logging and auditing procedures to track pipeline execution, monitor anomalies, and facilitate debugging.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The new ETL/ELT framework significantly improved the consistency, reliability, and performance of data processing workflows:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAchieved a 35% reduction in average pipeline execution time.\u003c/li\u003e\n\u003cli\u003eIncreased data pipeline throughput by over 50%, enabling near real‑time data availability for reporting.\u003c/li\u003e\n\u003cli\u003eReduced data quality issues by eliminating over 90% of transformation errors through better constraint enforcement and validation logic.\u003c/li\u003e\n\u003cli\u003eEnhanced maintainability and scalability, supporting future data model changes with minimal rework.\u003c/li\u003e\n\u003c/ul\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/architected-developed-implemented-supported-infrastructure-data-processing-and-55/","url":"https://engineer.company/portfolio/architected-developed-implemented-supported-infrastructure-data-processing-and-55/","title":"Architected, developed, implemented, supported infrastructure, data processing, and the map application for 2 years non‑stop without any weekends, holidays, or vacations, 10‑14 hours a day.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e An early‑stage green‑energy startup depended on a single platform to track, monitor, and optimize renewable energy assets, yet had neither a dedicated infrastructure team nor an established engineering organization to build and operate it. The entire technical foundation — cloud infrastructure, data‑processing pipelines, and the customer‑facing GIS map application — had to be created and kept running continuously, in a market where any downtime or data gap directly eroded customer trust and revenue.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The task was to single‑handedly architect, build, and operate the whole system end to end, spanning platform and data engineering, DevOps, and site reliability. Beyond writing the software, this meant owning production: provisioning and hardening infrastructure, designing the data‑processing layer that fed the map, and guaranteeing the application stayed available around the clock for a growing customer base — all within the constraints and relentless pace of a fast‑moving startup.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e For two years the infrastructure, data pipelines, and map application were designed, implemented, and supported without interruption — no weekends, holidays, or vacations, often ten to fourteen hours a day. A pragmatic, modular architecture was chosen to keep a one‑person operation maintainable, with automated provisioning, monitoring, and alerting so issues could be detected and resolved quickly. Data processing was continuously tuned for reliability and performance, releases were shipped incrementally, and every layer — from servers to the user‑facing map — was personally maintained and improved in response to real customer usage.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The platform stayed continuously available and evolved from a fragile early prototype into the dependable backbone of the product, sustaining the company through its critical growth phase on the strength of a single engineer\u0026rsquo;s ownership. This hands‑on stewardship kept infrastructure, data, and the map application reliable enough to support upsells, data licensing, and new‑customer acquisition, and demonstrated a rare degree of commitment, breadth, and end‑to‑end accountability across the full stack.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/optimized-budget-costs-10-times-with-zero-loss-56/","url":"https://engineer.company/portfolio/optimized-budget-costs-10-times-with-zero-loss-56/","title":"Optimized budget costs 10 times with zero loss in productivity for the Saudi Arabia company by reimagining the overall infrastructure, eliminating unnecessary services, and relocating from the AWS cloud.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A company operating out of Saudi Arabia was carrying badly bloated infrastructure costs. Their AWS setup had been over‑provisioned and had collected services they no longer used, so the cloud bill had drifted completely out of proportion to what the business actually needed. It\u0026rsquo;s a common story — nobody sets out to overspend, it just accretes when no one\u0026rsquo;s watching the meter.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The engagement was to cut the costs substantially without losing any productivity, which meant rethinking the infrastructure properly rather than trimming round the edges — edge‑trimming rarely moves a bill that\u0026rsquo;s structurally too big.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e So the work went end to end. First came an audit of what was actually being used — which is where the duplicated and unnecessary services show themselves — and those got cut. Then whatever was left was right‑sized to match real demand instead of the worst‑case guesses the original setup had been built on. And the big move was relocating the workloads off AWS entirely, onto a more cost‑effective hosting arrangement — done carefully, in stages, so the running business never felt the migration happening underneath it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The budget costs fell roughly ten‑fold, with zero loss in productivity — the same capability at a fraction of what they\u0026rsquo;d been paying. It freed up a real amount of money that had quietly been leaking into an oversized cloud bill month after month, which for the business was money straight back to the bottom line.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/architected-a-layered-maritime-platform-separating-a-next-57/","url":"https://engineer.company/portfolio/architected-a-layered-maritime-platform-separating-a-next-57/","title":"Architected a layered maritime platform separating a Next.js PWA frontend, a Go (Huma/Fiber) API, and a PostgreSQL function layer, keeping all business logic in the database.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner was going to be a maritime platform — professional networking, company reviews, sponsored education — and it was a young product, which is a polite way of saying the requirements were going to move around a lot. The thing to avoid was an architecture where changing a business rule meant touching the frontend, the API and the database all at once. On a small codebase that grows fast, that kind of coupling is what turns a two‑line change into an afternoon.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e As the architect, the call to make up front was where each kind of logic lived, with boundaries obvious enough to hold up under pressure instead of blurring the first time someone was in a hurry.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e It settled into three layers, one job each. The Next.js frontend does presentation and interactivity and nothing else. The Go API — Huma over Fiber — is deliberately thin: it routes, validates the request, applies the security filtering and orchestrates, but it holds no business logic at all. The business logic all lives in PostgreSQL functions, which assemble the full result and hand it back for the API to forward. So when a rule changes, it changes in one layer, in SQL, and the other two don\u0026rsquo;t need to know. The boundaries were written down and then enforced in review, because a convention nobody polices stops being one.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The thing stayed easy to hold in your head. Business logic sits in one place you can actually audit, the API is a boring adapter in the good sense, and the frontend doesn\u0026rsquo;t care when the schema shifts underneath it. That separation is what let the product keep bolting on features without the architecture quietly rotting.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-a-json-passthrough-architecture-where-postgresql-functions-58/","url":"https://engineer.company/portfolio/designed-a-json-passthrough-architecture-where-postgresql-functions-58/","title":"Designed a JSON passthrough architecture where PostgreSQL functions return complete JSON forwarded verbatim by the Go API, eliminating intermediate unmarshalling and decoupling the frontend from schema changes.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The usual way data gets from a database to a browser is a relay race of transformations. The database hands the API rows, the API unmarshals them into structs, reshapes them, serialises them back to JSON, and only then do they go out. Every one of those hops is code you write, code you test, and one more place where the API\u0026rsquo;s idea of the data and the database\u0026rsquo;s idea of it can drift apart.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The idea was to skip the relay race. If the database could return the finished response, the API could just pass it along, and the frontend could depend on the database\u0026rsquo;s shape directly instead of on a hand‑maintained copy of it living in Go.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e So it was built as a straight passthrough. The PostgreSQL functions assemble the whole response as JSON — the shaping is a SQL concern, done where the data already is. The Go handler takes that back as json.RawMessage and forwards it untouched; it never decomposes it, never re‑encodes it. A small QueryJSON helper made that pattern the path of least resistance rather than something you had to remember to do. What fell out was all the intermediate machinery a conventional layered API collects — the DTOs, the mappers, the response structs.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Handler code got dramatically shorter, and more to the point the frontend stopped being coupled to Go. Change what a function returns and the new shape flows straight through to the client without anyone editing a line of handler code. Fewer moving parts, and one whole category of layer‑to‑layer drift simply doesn\u0026rsquo;t exist here.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-an-organization-context-switching-system-with-client-59/","url":"https://engineer.company/portfolio/designed-an-organization-context-switching-system-with-client-59/","title":"Designed an organization context‑switching system with client localStorage and server‑side cookie mirroring, letting users act as managed organizations while enforcing least‑privilege authorization.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e On NextMariner a maritime professional can manage organizations — companies, academies — that don\u0026rsquo;t have their own logins. The person is the account; the organization is something they act on behalf of. So a user needs to move through the whole app as any organization they manage, switching between them freely, and that convenience can\u0026rsquo;t turn into a hole in the authorization.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Context‑switching had to be quick and unobtrusive for the user while making sure the active context could never, on its own, hand someone access they weren\u0026rsquo;t entitled to.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e An OrganizationContext handles it, with storage on both sides. On the client, localStorage is the source of truth for which organization you\u0026rsquo;re currently acting as, so switching is instant — no round‑trip. A server‑side cookie mirrors it so that server‑rendered pages resolve the same context during SSR; there\u0026rsquo;s a getServerViewMode on the server that reads it. The important part is that none of that is trusted for access decisions. Authorization gets re‑checked on the server on every request. The frontend context is there for the experience — showing you the right thing — and the server is the only authority on what you\u0026rsquo;re allowed to do.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e A user can act as any organization they manage without friction, and the interface stays in sync on both client and server. But because permissions are verified server‑side every time, none of that convenience weakens the security. Someone tampering with what\u0026rsquo;s in localStorage changes what their own UI shows them and nothing more — the server still says no.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/migrated-the-http-api-from-fiber-to-huma-60/","url":"https://engineer.company/portfolio/migrated-the-http-api-from-fiber-to-huma-60/","title":"Migrated the HTTP API from Fiber to Huma v2, gaining automatic request validation and OpenAPI modeling across all endpoints.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The API started life on Fiber, with request validation written out by hand, endpoint by endpoint. That\u0026rsquo;s fine when there are a handful of endpoints. It stops being fine as the surface grows: the hand‑rolled validation turns into a maintenance tax, and small inconsistencies creep in because every endpoint\u0026rsquo;s checks are their own little snowflake. And there was no single description of the API\u0026rsquo;s shape anywhere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The goal was validation coming from the types instead of from hand‑written checks, and an actual contract describing the API — without stopping to do a big‑bang rewrite.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The HTTP layer moved onto Huma v2, sitting on top of Fiber, so the existing runtime stayed. Each endpoint gets input and output structs, and Huma generates the request validation and response modelling from those types. An OpenAPI description comes out of it for free, which means the documentation tracks the code instead of rotting in a wiki. Everything new got written against Huma and the existing routes migrated over, with exactly two endpoints left on raw Fiber — the WebSocket ones, where you genuinely want the socket and Huma\u0026rsquo;s request/response model doesn\u0026rsquo;t fit.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e New endpoints get validation and current documentation without anyone doing extra work for it, and a whole class of request‑handling bugs — the \u0026ldquo;oh, we forgot to check that field here\u0026rdquo; kind — went away. The typed contract made the API both safer to change and easier to hand to someone else, because the types tell you what an endpoint expects.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/built-a-request-schema-validation-contract-with-automated-61/","url":"https://engineer.company/portfolio/built-a-request-schema-validation-contract-with-automated-61/","title":"Built a request‑schema validation contract with automated guards that catch frontend/backend payload mismatches before they reach production.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Frontend and backend move at their own pace, and their assumptions about a request payload can drift apart without anyone noticing. The way you usually find out is a 422 in the browser — after the mismatch has already shipped, which is the most expensive moment to learn about it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The goal was those mismatches caught by the pipeline, automatically, before they could reach a user.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A contract check runs in CI — api‑contract‑check.sh — comparing what the frontend sends against what the API actually expects, and failing the build on any divergence. There\u0026rsquo;s a schema probe underneath it that checks the real shapes rather than a description of them. It deliberately covers the cases where drift likes to hide: optional body fields, where \u0026ldquo;missing\u0026rdquo; and \u0026ldquo;null\u0026rdquo; get confused, and query‑parameter enums, where the two sides can quietly disagree on the allowed values. Rather than trusting people to keep frontend and backend in step by hand, the check does it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The two halves stay in lockstep. A payload mismatch fails a build instead of surprising a user, which took out a recurring and genuinely annoying class of bug — the kind that\u0026rsquo;s invisible in code review and only shows up at runtime. And because it runs in the pipeline, a contributor gets told quickly when a change would break the contract, while the fix is still cheap.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/implemented-startup-mail-provider-validation-across-three-providers-62/","url":"https://engineer.company/portfolio/implemented-startup-mail-provider-validation-across-three-providers-62/","title":"Implemented startup mail‑provider validation across three providers (SendGrid, SMTP2GO, Azure ACS) with environment‑aware behaviour — logging in development, failing the boot in staging and production.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Email carries a lot of weight on NextMariner — verification, notifications, the things a user actually waits for. And a mail provider is exactly the kind of dependency that fails quietly: the config looks fine, the app boots, and you only find out something\u0026rsquo;s broken when a real person never gets the message they were promised. That\u0026rsquo;s the worst way to learn about it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The app needed to check, at startup, that mail actually worked, and to be loud about it in the environments where it matters, without turning a routine local run into a nuisance.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e So provider validation went into the boot sequence, behind a MAIL_VALIDATE_ON_START flag. It sends a real test through the provider stack — SendGrid as primary, with SMTP2GO and Azure Communication Services behind it as fallbacks — and how it reacts depends on where it\u0026rsquo;s running. In develop it just logs a warning and carries on; nobody wants their laptop refusing to start because a sandbox key expired. In staging and production a failure is fatal: the process exits rather than deploy a build that can\u0026rsquo;t send mail. The send itself goes through an SSRF‑protected client with a 30‑second timeout, and the async delivery path has its own retries and backoff so a momentary blip doesn\u0026rsquo;t drop a message.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e A whole category of silent failure moved from \u0026ldquo;a user notices days later\u0026rdquo; to \u0026ldquo;the deploy stops.\u0026rdquo; Where broken email is a real problem it can\u0026rsquo;t slip through; on a developer\u0026rsquo;s machine it stays out of the way. Same check, different volume depending on who\u0026rsquo;s watching.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-a-postgresql-function-first-data-layer-across-63/","url":"https://engineer.company/portfolio/designed-a-postgresql-function-first-data-layer-across-63/","title":"Designed a PostgreSQL function‑first data layer across the platform's domain schemas (identity, organization, review, message, notification and more), exposing all data access through stored functions.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Business logic has a way of leaking. A bit ends up in the API, a bit in some SQL a handler runs inline, and before long the same rule is written two or three slightly different ways and there\u0026rsquo;s nowhere you can point to and say \u0026ldquo;this is what the system does with its data.\u0026rdquo; That\u0026rsquo;s how bugs and security holes get in.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The goal was one home for all of it: every read and write going through the database, the API a thin adapter that doesn\u0026rsquo;t know the business rules, and the whole thing lockable down tight.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The data layer is function‑first. The schema is split by domain — identity, organization, review, message, notification, and a couple of dozen more — and every operation the app can do is a PostgreSQL function it calls; there\u0026rsquo;s no direct table access from Go at all. Then the database enforces it. The role the API logs in as, mariner, has EXECUTE on the app functions and USAGE on the schemas and nothing else — no SELECT, no INSERT, no way to touch a table directly. The functions run SECURITY DEFINER, owned by a separate non‑login function_owner role with a pinned search_path, and the superuser account stays reserved for migrations and cron, well away from the running app.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The logic lives in one place you can actually audit, the API stays thin and boring in the good way, and the access boundary is enforced by Postgres itself rather than by everyone remembering the rules. If the API were somehow compromised, it still couldn\u0026rsquo;t do anything the functions don\u0026rsquo;t allow.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/adopted-uuid-v7-time-ordered-identifiers-postgresql-18-64/","url":"https://engineer.company/portfolio/adopted-uuid-v7-time-ordered-identifiers-postgresql-18-64/","title":"Adopted UUID v7 time‑ordered identifiers (PostgreSQL 18) as entity keys to reduce B‑tree index fragmentation and speed up queries.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Every entity needs a unique id, and the reflex choice is a random UUID. The trouble is that random ids land all over a B‑tree index. Inserts scatter, the index fragments, and as tables grow both writes and range scans pay for it. On a platform meant to keep growing, that\u0026rsquo;s a slow leak you\u0026rsquo;d rather not build in.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Keep the global uniqueness of a UUID but drop the fragmentation that comes with the randomness.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The standard became UUID v7, which is time‑ordered — the leading bits are a timestamp, so new rows sort into the index instead of peppering it. PostgreSQL 18 has this natively as uuidv7(), wrapped in a small uuid_generate_v7() function so the same call behaves cleanly on Azure\u0026rsquo;s Flexible Server, then made the default for entity primary keys across the schema. Nothing exotic about it; it\u0026rsquo;s the kind of decision that\u0026rsquo;s cheap if you make it early and a pain to retrofit later.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Ids stayed globally unique, the index stopped fragmenting the way random UUIDs cause, and time‑ordered inserts and range queries got quicker — evenly, across every table, without anyone having to think about it again. As a bonus, every entity ends up with a key you can sort by time for free.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/implemented-a-catalogue-driven-deep-merge-for-stored-65/","url":"https://engineer.company/portfolio/implemented-a-catalogue-driven-deep-merge-for-stored-65/","title":"Implemented a catalogue‑driven deep‑merge for stored JSON preferences, preventing missing‑key crashes as the schema evolves.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The platform stores JSON preferences — notification settings and the like — as a user\u0026rsquo;s saved values laid over a set of defaults. The original merge did that at a single level. The problem shows up later: add a new key to the defaults, and rows saved before that key existed simply don\u0026rsquo;t have it. Then some client code reads that field, gets undefined, and falls over — for exactly the users who\u0026rsquo;ve been around longest.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Evolving the preference schema had to be safe, so that adding a setting could never break the people who signed up before it existed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The single‑level merge was replaced with a deep‑merge driven by the defaults as a catalogue. The defaults are treated as the authoritative list of every key that should exist; the user\u0026rsquo;s stored values are merged recursively on top, so anything in the catalogue is guaranteed to come out present, whether or not it was in the saved blob. Add a key to the defaults and it appears in every existing row\u0026rsquo;s effective preferences automatically, nested keys included. It rolled in through a migration so existing data got the benefit straight away rather than waiting to be rewritten.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Preferences can grow without fear. Adding a setting no longer risks an undefined‑field crash in the client, and the frontend stopped needing defensive checks scattered around every place it reads a preference. It also gave the rest of the platform a dependable way to extend any stored‑JSON blob — the pattern, not just the one fix.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/built-a-python-vessel-data-scraper-marinetraffic-maritime-66/","url":"https://engineer.company/portfolio/built-a-python-vessel-data-scraper-marinetraffic-maritime-66/","title":"Built a Python vessel‑data scraper (MarineTraffic, Maritime‑Database) and imported roughly 700 maritime companies to seed the platform's core reference data.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A maritime networking‑and‑reviews site is dead on arrival if it\u0026rsquo;s empty. Nobody joins a directory with no companies in it. So before any of the social features mattered, the platform needed a real body of maritime companies and vessels already sitting there, ready to be found.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Go and get that data — real companies, at enough scale to feel populated — and get it into the database in a way that could be rerun, not a one‑off scrape nobody could reproduce.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The scrapers are written in Python. One drives MarineTraffic with Playwright; another pulls from Maritime‑Database over async httpx; there\u0026rsquo;s a ClassNK fetcher in there too. They write out CSVs, and an import step cleans and normalises those and loads them into the Postgres schema through a task (docker‑dat‑populate‑companies), so seeding the database is a single command rather than an afternoon of manual work. The company set came out to around 700.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The platform launched with roughly 700 real maritime companies in it instead of empty tables — a directory that actually looked like something on day one, and a base of reference data the networking, jobs and review features could all build on top of. And because the pipeline is repeatable, refreshing or extending it later is just running it again.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/modeled-the-maritime-domain-professionals-companies-ships-jobs-67/","url":"https://engineer.company/portfolio/modeled-the-maritime-domain-professionals-companies-ships-jobs-67/","title":"Modeled the maritime domain — professionals, companies, ships, jobs and reviews — into normalized PostgreSQL schemas with SMALLINT lookups and UUID v7 keys.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The heart of NextMariner is a dense maritime domain — professionals, companies, ships, jobs, reviews — and these things reference each other constantly. A professional sails on ships, works for companies, leaves reviews; a company owns ships and posts jobs. Nearly every feature is a query across that web, so how well the data is modelled decides how well most of the app performs and how sane it is to extend.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e That domain had to be modelled so it stayed fast and kept its integrity, and so that adding the next entity type didn\u0026rsquo;t mean fighting the schema.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e It\u0026rsquo;s laid out as normalized PostgreSQL schemas organised by domain. The many small, stable enumerations — statuses, types, categories — became SMALLINT lookup tables, which keeps the rows compact and the joins cheap instead of storing text codes everywhere. Entities get UUID v7 primary keys, so they\u0026rsquo;re globally unique but still time‑ordered in the index. One naming convention runs throughout — plural table names inside singular‑named schemas — applied without exception, which as a bonus sidesteps a lot of reserved‑word collisions. And the relationships are held up by real foreign keys and constraints, so integrity is the database\u0026rsquo;s job, not something the application has to remember to do.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e What came out is a data model that\u0026rsquo;s consistent and quick, and predictable to work in because the same rules hold everywhere — there aren\u0026rsquo;t special cases to memorise. Adding a feature usually means extending the schema along the existing grain rather than working against it. It\u0026rsquo;s the floor the rest of the platform stands on.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/provisioned-azure-infrastructure-as-code-with-bicep-container-68/","url":"https://engineer.company/portfolio/provisioned-azure-infrastructure-as-code-with-bicep-container-68/","title":"Provisioned Azure infrastructure as code with Bicep — Container Apps, PostgreSQL Flexible Server, Front Door/WAF and networking — across the development, staging and production environments.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner lives on Azure, and Azure done by hand — clicking through the portal, tweaking a setting here and there — is a trap. It drifts, nobody remembers why something is the way it is, and rebuilding it after a bad day is slow and nerve‑wracking. With more than one environment to keep in step, that only gets worse.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Put the whole thing in code, so an environment is something you can read, review and recreate rather than a pile of manual state.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The estate is defined in Bicep. Each environment — testing, staging, product — comes out of the same templates: the api and www running as Azure Container Apps on a managed environment, a PostgreSQL Flexible Server, Redis for caching, Front Door with a WAF policy out in front, and the networking underneath it (VNet, NSG, private DNS), with Log Analytics wired in for diagnostics. Images are pulled from the project\u0026rsquo;s Azure Container Registry. Because it\u0026rsquo;s all parameterised, standing up a fresh environment or changing an existing one is a pull request, not a support ticket to yourself.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The environments became reproducible and reviewable. Drift stopped being a mystery, because the source of truth is the code, and bringing infrastructure up or back is a matter of applying the templates rather than remembering what got clicked last time. It\u0026rsquo;s the difference between infrastructure you own and infrastructure that owns you.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/built-github-actions-ci-cd-pipelines-with-a-69/","url":"https://engineer.company/portfolio/built-github-actions-ci-cd-pipelines-with-a-69/","title":"Built GitHub Actions CI/CD pipelines with a distroless production frontend image and multi‑environment promotion.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Shipping shouldn\u0026rsquo;t depend on someone remembering the steps, and what ends up running in production shouldn\u0026rsquo;t be a fat general‑purpose container carrying a shell and a package manager it\u0026rsquo;ll never use — that\u0026rsquo;s just attack surface sitting there for no reason.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Make the path from commit to running‑in‑Azure automatic, and keep the production images as small and locked‑down as each workload allows.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The pipeline is GitHub Actions. Separate workflows handle the code‑quality gate, the tests, and the per‑environment deploys, with CodeQL, dependency review and an SBOM step alongside them, so nothing reaches an environment without passing the checks first. The images are multi‑stage builds, and the base for each part was picked on its merits rather than as one blanket choice: the frontend ships on a distroless image (gcr.io/distroless/cc‑debian13 — no shell, no package manager), the Go API on a slim Alpine, and the database image on postgres‑slim. Promotion moves a build through the environments along a defined route rather than by hand.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Releases stopped being a careful manual ritual and became a routine, boring event, which is exactly what you want from releases. The production frontend runs on about as little as you can give it, the checks catch problems before they land, and \u0026ldquo;deploy\u0026rdquo; is something the pipeline does rather than something anyone sweats through.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/authored-300-go-task-automation-targets-spanning-native-70/","url":"https://engineer.company/portfolio/authored-300-go-task-automation-targets-spanning-native-70/","title":"Authored 300+ go‑task automation targets spanning native, Docker and HTTPS dev modes, linting, testing, database and deployment.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner is a polyglot monorepo — Go, TypeScript, SQL, Python, shell — and every one of those brings its own way to build, test, lint and run. Left alone, that means everyone carrying a mental cheat‑sheet of tool‑specific commands, and newcomers spending their first day just working out how to make things go.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Give the whole project one front door: a single, consistent way to run anything, whatever language it happens to be written in.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e That\u0026rsquo;s built out with go‑task — a Taskfile layer that\u0026rsquo;s grown to somewhere north of 340 named targets across fifteen or so namespaces. There are the development modes (native, Docker, an HTTPS variant for testing PWA and mobile), the code‑quality side (lint, format, test, fix across all the languages), database management, and the environment‑specific build and deploy tasks. There\u0026rsquo;s even a low‑memory mode for machines that can\u0026rsquo;t spare the RAM to build the frontend the usual way. The point was never to have a lot of tasks; it was that you never have to know the underlying command.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Anyone can run task \u0026ndash;list and see the whole toolchain laid out, and run any part of it the same way regardless of what\u0026rsquo;s under the hood. Onboarding got shorter, and the small, stupid mistakes — wrong flag, wrong directory, half‑remembered command — mostly went away. One memorable entry point instead of a dozen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/owned-end-to-end-deployments-of-the-platform-71/","url":"https://engineer.company/portfolio/owned-end-to-end-deployments-of-the-platform-71/","title":"Owned end‑to‑end deployments of the platform to Azure, managing releases across development, staging and production environments.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The platform had to reach users across several Azure environments, and deployment is the seam where the infrastructure, the build pipeline and the application all meet. It\u0026rsquo;s also where a small mistake stops being a bug and becomes an outage, so it\u0026rsquo;s the part you least want to be doing by hand and half from memory.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Deployment was owned end to end, so that a change moved out to each environment the same predictable way every time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Releases move along a fixed route — development, then staging, then production — rather than anyone pushing straight to a live environment. The CI/CD pipeline builds the images and ships them, and the Bicep templates keep the target infrastructure identical from one environment to the next, so a build isn\u0026rsquo;t promoted into a subtly different place each time. Configuration that differs per environment is kept separate from the secrets, which means the same built artefact can be promoted through the environments and just picks up the right settings where it lands, instead of being rebuilt for each one.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Changes reach each environment predictably, along a defined path, with no ad‑hoc manual deploys in the mix. Releasing turned into a controlled, repeatable step instead of a held‑breath moment, and that\u0026rsquo;s a big part of what kept the live platform stable while it was still changing quickly underneath.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/implemented-database-backups-and-a-disaster-recovery-strategy-72/","url":"https://engineer.company/portfolio/implemented-database-backups-and-a-disaster-recovery-strategy-72/","title":"Implemented database backups and a disaster‑recovery strategy backed by infrastructure‑as‑code for fast, reproducible recovery.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A product that lives on its data can\u0026rsquo;t afford to lose any, and \u0026ldquo;there are backups somewhere\u0026rdquo; is a hope, not a recovery plan. The only backup worth having is one you know restores, into an environment you know you can rebuild. NextMariner needed both halves of that, not just the first.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Recovery had to be guaranteed — the data and the environment around it — quickly, and in a way that could actually be reproduced rather than improvised on a bad day.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The database is backed up with retention configured, so a restore can go to a point in time rather than just to last night. The environment around it is defined as infrastructure‑as‑code in Bicep, which is the quiet half people forget: restoring a database into an environment you\u0026rsquo;d have to rebuild by hand from memory isn\u0026rsquo;t really recovery. Because both pieces are covered, getting back means restoring data into an environment that stands up from its templates — a procedure, not a scramble.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The data is recoverable and the platform can be brought back quickly, which turned disaster recovery from a nagging background worry into something with defined steps. For a young company that mattered as much psychologically as technically: a failure would be a bad day you recover from, not the kind of thing that ends the product.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/built-the-next-js-16-frontend-with-ssr-73/","url":"https://engineer.company/portfolio/built-the-next-js-16-frontend-with-ssr-73/","title":"Built the Next.js 16 frontend with SSR, SSG and CSR strategies and a server‑shell prefetch‑and‑hydrate pattern that eliminated N+1 fetches.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The authenticated dashboard needed to feel quick and stay genuinely interactive, and those two goals pull against each other if you\u0026rsquo;re naïve about it. Fetch everything on the client and the first load drags, and worse, you get the N+1 pattern where every component wakes up and fires its own request, so a single page turns into a cascade of round‑trips.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Each part of the app needed rendering the way that actually suited it, without giving up the client‑side interactivity where it mattered.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The Next.js 16 frontend uses the right mode per surface instead of one blanket choice. Marketing and public pages are statically generated — they don\u0026rsquo;t change per user, so there\u0026rsquo;s no reason to render them on every request. Authenticated pages are server‑rendered, with a server‑shell prefetch‑and‑hydrate pattern — createPrefetchedServerPage — that fetches the page\u0026rsquo;s data on the server and hands it to the client already populated, so the components come up with their data instead of each going off to ask for it. The genuinely interactive parts stay client‑rendered. And a cache‑invalidation strategy is documented per query, so data stays fresh without the app re‑fetching things it already has.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Pages load fast and stay fully interactive, and the N+1 storm on the dashboard just went away, because the server shell brings back what the page needs in one go. The frontend ended up with the perceived speed of server rendering and the responsiveness of a client app, instead of having to pick one.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/delivered-full-progressive-web-app-support-installable-and-74/","url":"https://engineer.company/portfolio/delivered-full-progressive-web-app-support-installable-and-74/","title":"Delivered full Progressive Web App support — installable and offline‑capable — with Workbox runtime caching via next‑pwa.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A lot of NextMariner\u0026rsquo;s users are at sea. Seafarers and field staff, on phones, frequently offline or hanging off a bad connection — not people sitting at a desk on reliable office wifi. Building as if everyone had a fast, constant network would have quietly excluded a big part of the actual audience.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The app had to be installable like a native one, and still usable when the network drops out.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e It\u0026rsquo;s delivered as a full Progressive Web App. It installs to the home screen with proper icons across the various sizes, a splash screen and theme colours, so it looks and launches like an app rather than a bookmark. The service worker is set up through the next‑pwa plugin, and Workbox runtime caching uses CacheFirst for the things that don\u0026rsquo;t change per request — fonts, images, audio, video, CDN assets — alongside sensible HTTP cache‑control headers. Because service workers only really behave over HTTPS, HTTPS‑based testing validated the offline and install behaviour on real devices instead of hoping it worked.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Users can install the app and keep using it offline, and repeat loads come back fast from cache instead of over the wire. The platform behaves like a native app on the hardware its users actually carry, which for this audience isn\u0026rsquo;t a nice‑to‑have — it\u0026rsquo;s the difference between the app being usable at sea and not.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-an-ios-26-liquid-glass-design-system-75/","url":"https://engineer.company/portfolio/designed-an-ios-26-liquid-glass-design-system-75/","title":"Designed an iOS 26 'Liquid Glass' design system and a canonical component inventory enforced by lint rules to prevent UI divergence.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A UI without a shared visual language and a fixed set of components drifts, and it drifts fast. Every new screen reinvents its own buttons and badges and cards, each a little different, and those small inconsistencies pile up until the product looks incoherent and every change means touching five bespoke versions of the same thing.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The design system had to be coherent enough to look deliberate, and enforceable enough that it wouldn\u0026rsquo;t erode the moment the team was busy.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The visual language and the component system were designed as one thing. The language is an iOS 26 \u0026ldquo;Liquid Glass\u0026rdquo; look — translucent panels with backdrop blur, layered shadows, a bit of refraction, spring animations — built out of Tailwind utilities. On top of it sits a canonical set of components every screen is supposed to compose from: Card, Label, Button, GlassIconButton, DirectoryGrid and the rest. The part that makes it stick is the linting: rules that reject a hand‑rolled badge or chip and point you at the canonical component instead, so the system is held up by tooling rather than by whoever\u0026rsquo;s reviewing that day remembering to care. And the docs are paired with concrete mistake‑to‑resolution notes, so the guidance is \u0026ldquo;here\u0026rsquo;s the wrong way and the right way,\u0026rdquo; not an abstract principle.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The UI stays consistent and on‑brand, and the one‑off components that would otherwise spread get caught before they do. Visual consistency stopped being a matter of everyone\u0026rsquo;s discipline and became something the tooling holds the line on, which is the only version of it that survives a deadline.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-the-product-s-ui-and-ux-end-76/","url":"https://engineer.company/portfolio/designed-the-product-s-ui-and-ux-end-76/","title":"Designed the product's UI and UX end to end — directory grids, dual card/table views, live requirement validators and breadcrumb navigation.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner puts a lot of different entities in front of people — professionals, companies, ships, jobs, reviews — and the interface had to be two things that fight each other: good‑looking and genuinely usable. Dense enough to show real maritime data, but not so dense it turns into a wall you bounce off.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The product\u0026rsquo;s UI and UX were owned end to end — the layouts, the interaction patterns, and the smaller stuff like how someone gets walked through a form without feeling nagged.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A few decisions did most of the work. The directory grids have a card/table toggle, so you can browse visually or scan a dense table, and the app remembers which you picked. Forms use live requirement validators that sit above the input and show each rule in green when it\u0026rsquo;s met and amber when it isn\u0026rsquo;t, so you\u0026rsquo;re guided while you type instead of scolded after you submit. Navigation is consistent breadcrumbs and two‑column entity layouts, so pages feel like the same product rather than a set of unrelated screens. And the error philosophy is guidance over failure — no red walls, redirects instead of dead ends, the app trying to keep you moving rather than stopping you.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e What came out is a polished, consistent experience that makes dense maritime data approachable and steers people through the complicated parts. It reads as considered and trustworthy, which isn\u0026rsquo;t cosmetic on a platform people are using for their actual careers — if it looked slapdash, they\u0026rsquo;d trust the data less, and they\u0026rsquo;d be right to.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/hardened-the-application-with-nonce-based-csp-hsts-77/","url":"https://engineer.company/portfolio/hardened-the-application-with-nonce-based-csp-hsts-77/","title":"Hardened the application with nonce‑based CSP, HSTS, SameSite cookies, least‑privilege database roles and server‑side entitlement re‑checks.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner holds professional and organizational data, the kind people expect to be handled properly, so a single line of defence was never going to be enough. The working assumption has to be that the client is hostile — that anything the browser enforces can be switched off by whoever\u0026rsquo;s holding the browser — and the security has to hold up anyway.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The platform had to be hardened at every layer — frontend, API, database — so that security was enforced by the server independently of whatever the interface happened to allow.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e On the frontend, the Next.js proxy middleware — proxy.ts — sets a Content‑Security‑Policy with a per‑request nonce and strict‑dynamic, plus HSTS and SameSite cookies, so the browser is locked down about what it\u0026rsquo;ll run and send. At the API, there\u0026rsquo;s rate limiting, CORS, request‑size limits, input validation before anything touches the database, and logging of the security‑relevant events. In the database, the API logs in as a least‑privilege role that can only EXECUTE the app functions, the functions run SECURITY DEFINER, and everything is parameterised. And the entitlements — tier, role, organization, ship scoping — are re‑checked on the server on every request, with the frontend gates treated as UX only. The gates decide what you see; the server decides what you can do.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Security doesn\u0026rsquo;t depend on the UI behaving. The protections are layered so that getting past one doesn\u0026rsquo;t get you past the rest, and the whole thing is built on the assumption that the client can\u0026rsquo;t be trusted — which is the right assumption for data people are handing over in confidence.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/established-an-english-danish-internationalization-system-with-linter-78/","url":"https://engineer.company/portfolio/established-an-english-danish-internationalization-system-with-linter-78/","title":"Established an English/Danish internationalization system with linter‑enforced vocabulary and a 400‑line namespace budget.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner runs in English and Danish, and translation systems have a way of sprawling into a mess. The files grow without limit, keys leak — present in one locale, missing in the other — and the language‑specific conventions get applied unevenly, so one locale ends up reading like it was translated by a committee that didn\u0026rsquo;t talk to each other. For a professional product that\u0026rsquo;s not a small blemish; it reads as carelessness.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The internationalization setup had to scale — keeping both languages consistent and correct, and the files something a person could still maintain a year in.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e It\u0026rsquo;s built on next‑intl with rules the tooling actually enforces. The Danish side has a locked vocabulary and style — literal æøå, the informal \u0026ldquo;du\u0026rdquo;, the right imperative accents, and semantic mappings for compound nouns so they\u0026rsquo;re translated by meaning rather than word‑for‑word — and a linter holds it to that. There\u0026rsquo;s a hard 400‑line budget per namespace, with a split‑and‑merge approach so a big area divides into nested files that merge back cleanly instead of one file growing forever. A linter check compares keys across locales so nothing leaks or goes missing. And stored overrides are merged catalogue‑driven rather than with fragile top‑level fallbacks — the same deep‑merge idea used for preferences.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Both locales stay correct and consistent, and the files stay maintainable as the string count climbs. Language quality became something the tooling guarantees on every commit rather than something that quietly degrades each time someone adds a string in a hurry.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/set-a-zero-warnings-quality-bar-across-six-79/","url":"https://engineer.company/portfolio/set-a-zero-warnings-quality-bar-across-six-79/","title":"Set a zero‑warnings quality bar across six languages — Go, TypeScript, SQL, Python, Shell and Markdown — enforced by pre‑commit hooks.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Warnings that pile up are quietly corrosive. Every diagnostic you ignore lowers the bar a little, and once the build spits out forty of them nobody reads any of them, and a real problem sits in that list in plain sight because \u0026ldquo;warnings\u0026rdquo; have become background noise. In a polyglot codebase there are that many more sources of noise to let it happen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The repo needed one uncompromising quality bar across every language, so things got fixed instead of accumulating.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A zero‑warnings policy went in, with the tooling as the thing that enforces it, because a policy that relies on everyone\u0026rsquo;s vigilance loses to the first busy week. Every linter diagnostic is an error — there\u0026rsquo;s no \u0026ldquo;warn\u0026rdquo; tier to hide in — and it\u0026rsquo;s the same across the whole stack: Go with golangci‑lint, TypeScript with ESLint, SQL with SQLFluff, Python with Ruff, shell with ShellCheck, Markdown with markdownlint. Inline suppressions are banned, so you can\u0026rsquo;t paper over a diagnostic; you have to actually fix the thing. Pre‑commit and pre‑push hooks run the linters and the tests, so a commit that would introduce a problem doesn\u0026rsquo;t get made in the first place. There are even function- and file‑length limits, to keep modules from sprawling past the point of being readable.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Problems get fixed at the source instead of deferred into a backlog nobody clears, and the codebase stays clean by default rather than by periodic heroics. The standard is identical whatever language you\u0026rsquo;re in, and it\u0026rsquo;s the tooling holding it — not anyone\u0026rsquo;s willpower — which is why it actually holds.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/architected-and-implemented-the-platform-end-to-end-80/","url":"https://engineer.company/portfolio/architected-and-implemented-the-platform-end-to-end-80/","title":"Architected and implemented the platform end to end — backend, database, frontend, design system, infrastructure and security — establishing the technical foundation and engineering standards.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner set out to build a whole maritime platform — professional networking, company reviews, educational sponsorships — from the ground up. And from the ground up meant everything had to exist at once: the data model, the API, the web experience, the design language, the cloud infrastructure, the security posture. There were no existing systems to lean on, and a young company moving quickly, which is exciting and a lot of rope to hang yourself with in equal measure.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e The platform architecture and the implementation were owned end to end. The job wasn\u0026rsquo;t just to make it work — it was to turn a product vision into a coherent, production‑grade system, making the technical calls across every layer and setting the engineering standards the codebase would grow inside, rather than piling up shortcuts to pay off later.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The full stack was designed and built so the layers fit together rather than each being locally clever. The data lives in PostgreSQL with function‑first business logic, UUID v7 keys and normalized maritime schemas. The Go API — Huma over Fiber — sits on top as a thin, validated, secure adapter over those functions and holds no business logic of its own. The frontend is a Next.js 16 PWA using SSR, SSG and CSR each where they fit, with a server‑shell prefetch‑and‑hydrate pattern, and it\u0026rsquo;s dressed in an iOS 26 \u0026ldquo;Liquid Glass\u0026rdquo; design system backed by a canonical, lint‑enforced component set. Underneath it all, the Azure infrastructure is defined in Bicep, shipped through CI/CD, with security layered from the nonce CSP down to least‑privilege database roles and server‑side entitlement checks. And the quality bar was set — a zero‑warnings policy across six languages, enforced by pre‑commit hooks — so the standard held from the first commit rather than being something to promise to clean up later.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e NextMariner came out of it with a complete, production‑grade platform — a clean, layered architecture with consistent standards the whole way through. Because the layers were designed to fit rather than bolted together, it\u0026rsquo;s a foundation that scales with the product and stays maintainable as the team and the feature set grow, instead of the kind of first version you end up having to throw away.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/delivered-analysis-and-regular-progress-reports-to-the-81/","url":"https://engineer.company/portfolio/delivered-analysis-and-regular-progress-reports-to-the-81/","title":"Delivered analysis and regular progress reports to the CEO, translating engineering metrics and delivery status into decisions.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e As the platform came together, its progress and its health had to be visible to leadership in terms they could actually do something with. Raw engineering signals — build status, delivery pace, incidents — don\u0026rsquo;t mean much on their own to someone making product and investment calls; they\u0026rsquo;re at the wrong altitude. Someone had to translate.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e That translation was the job: taking the engineering reality — where delivery stood, what the system metrics were saying — and reporting it to the CEO clearly and regularly, so decisions rested on facts instead of guesswork.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A steady reporting rhythm went in, rather than reporting when asked, which is always a bit too late. Delivery progress, scope, risks and system health got tracked and turned into plain, decision‑oriented updates — what\u0026rsquo;s on track, what\u0026rsquo;s at risk, and what a given priority would actually cost in trade‑offs. The thing to avoid was handing over raw numbers and leaving the interpretation to someone without the context; each report came with concrete recommendations, and where it helped the narrative was backed with the underlying analysis, so leadership could drill in if they wanted rather than having to take it on trust.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Leadership ended up with a clear, honest, current picture of the engineering, and could steer product priorities and investment with some confidence instead of flying blind. Reporting stopped being a status ritual nobody reads and became something decisions actually got made from — which kept the technical work and the business direction pointed the same way.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/provided-round-the-clock-24-7-infrastructure-support-82/","url":"https://engineer.company/portfolio/provided-round-the-clock-24-7-infrastructure-support-82/","title":"Provided round‑the‑clock 24/7 infrastructure support for an IPTV/OTT streaming platform, administering ~1,000 servers plus client‑owned systems for global customers in China, the US and Germany.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e This was an IPTV/OTT streaming platform with customers spread across China, the US and Germany, which meant there was no quiet hour to do maintenance in — someone, somewhere, was always watching. Downtime on a platform like that isn\u0026rsquo;t an abstract metric; it\u0026rsquo;s someone\u0026rsquo;s television just stopping, and they don\u0026rsquo;t care why.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Keeping the platform\u0026rsquo;s infrastructure available around the clock was the job — genuinely around the clock, not \u0026ldquo;business hours plus an on‑call rota nobody answers.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e 24/7 support ran for roughly a thousand servers, plus a good number of client‑owned systems on top of that — administering them, monitoring them, keeping them secured and configured across the whole streaming estate. Because customers sat in three very different time zones, \u0026ldquo;after hours\u0026rdquo; didn\u0026rsquo;t really exist; a problem at 3am local was primetime for someone else, so it got treated as primetime. A lot of the work was noticing something drifting before it became an outage, because on a live streaming platform you don\u0026rsquo;t get to fix things quietly after the fact.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The platform stayed continuously available for a global audience, with problems caught and dealt with at whatever hour they turned up, before they reached a viewer\u0026rsquo;s screen. On a 24/7 service that\u0026rsquo;s the whole job — success looks like nothing happening, which is exactly what the viewers wanted.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/ensured-uninterrupted-delivery-of-iptv-streaming-signals-between-83/","url":"https://engineer.company/portfolio/ensured-uninterrupted-delivery-of-iptv-streaming-signals-between-83/","title":"Ensured uninterrupted delivery of IPTV streaming signals between suppliers and clients, monitoring and maintaining the streaming network and IP telephony around the clock.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e IPTV lives or dies on the signal getting through. The streams flow from suppliers, through the platform, to the clients, and any break anywhere in that chain is a black screen for someone. The IP telephony sat alongside it, with the same requirement: it just had to work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Guaranteeing that the signal delivery and the telephony stayed uninterrupted was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The streaming network and the IP telephony were monitored, troubleshot and maintained around the clock. The point of watching it constantly is that streaming problems announce themselves as degradation before they become an outright drop — a stream that starts stuttering, a link that\u0026rsquo;s getting flaky — and if you\u0026rsquo;re paying attention you can catch it at the stutter instead of the black screen. So a lot of it was staying ahead of the signal rather than reacting to complaints about it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The streams and the calls stayed reliable across the platform, with problems detected and fixed before they turned into service anyone noticed dropping. Keeping a signal flowing between suppliers and end clients without a visible gap is quiet, constant work, and quiet is what it should be.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/developed-and-maintained-django-web-applications-for-the-84/","url":"https://engineer.company/portfolio/developed-and-maintained-django-web-applications-for-the-84/","title":"Developed and maintained Django web applications for the IPTV platform, shipping new features and improving performance and stability.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The IPTV platform had web applications built on Django around it — the parts people actually clicked on — and they needed to keep moving forward: new features, and the performance and stability that a platform running around the clock demands.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Keeping those applications feature‑rich, fast and stable was the task.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The Django web applications were developed and maintained — building new features, fixing the bugs, and pushing on performance and stability, worked across the team rather than in a corner. On something serving customers continuously, the stability side isn\u0026rsquo;t a nice‑to‑have alongside the features; it\u0026rsquo;s the constraint the features have to respect. A flashy feature that makes the thing wobble isn\u0026rsquo;t worth much when the thing can\u0026rsquo;t afford to wobble.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The applications kept gaining capability while staying reliable for both the internal teams and the customers. Adding to something without destabilising it is the balance that mattered here, and that\u0026rsquo;s what the work held to.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/planned-and-implemented-new-infrastructure-functionality-for-internal-85/","url":"https://engineer.company/portfolio/planned-and-implemented-new-infrastructure-functionality-for-internal-85/","title":"Planned and implemented new infrastructure functionality for internal and external systems, building solutions durable enough to still run years later with minimal change.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e As the organisation grew, its internal and external systems kept needing new capabilities bolted on. The easy way to do that is whatever\u0026rsquo;s quickest today; the trouble with the easy way is you\u0026rsquo;re back fixing it in six months.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Planning and building infrastructure functionality that would actually last was the task — not just work now, but keep working.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e New infrastructure functionality was planned and implemented across the internal and external systems, designed to be durable — the kind of thing you build once, properly, so it keeps running for years with minimal touching rather than needing constant attention. That\u0026rsquo;s a deliberate choice each time: spend a bit more thought up front so you\u0026rsquo;re not signing yourself up to babysit it forever.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The systems stayed functional and effective long after they were built, running for years with barely any change. That longevity is the real measure of infrastructure work — anyone can make something that works today; making something that\u0026rsquo;s still quietly working years later is the harder and more useful thing.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/as-one-of-the-first-hires-designed-and-86/","url":"https://engineer.company/portfolio/as-one-of-the-first-hires-designed-and-86/","title":"As one of the first hires, designed and built the entire core infrastructure and supporting processes from scratch for a green‑energy SaaS startup, laying the foundation for rapid growth.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e This was a green‑energy SaaS startup with a promising idea and essentially no technical foundation under it yet. Coming in as one of the first hires meant the stage where there\u0026rsquo;s nothing to maintain because nothing exists — building the ground everyone else will stand on.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Building the core infrastructure and the processes around it, from scratch, was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The entire core infrastructure and its supporting processes were designed and built — the servers, the networks, the data flow, the security, the operations side. Doing that at a startup means making decisions that are hard to unmake later, so the goal wasn\u0026rsquo;t just \u0026ldquo;get something running,\u0026rdquo; it was to lay a foundation that could take the weight of rapid growth without needing to be ripped out the moment the company got bigger. Early infrastructure choices either become the thing that lets you scale or the thing you spend a year undoing; the aim was firmly the first kind.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The startup came away with a solid technical foundation, and it\u0026rsquo;s what let the business grow quickly afterward. Being the person who builds that base from nothing is a particular kind of responsibility — get it right and nobody notices, get it wrong and everyone does — and this one held up.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/maintained-and-enhanced-the-legacy-hugo-static-site-87/","url":"https://engineer.company/portfolio/maintained-and-enhanced-the-legacy-hugo-static-site-87/","title":"Maintained and enhanced the legacy Hugo static‑site website while contributing UI/UX improvements to the primary asset‑management product.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e There was a legacy website built on Hugo — a static‑site generator — running alongside the company\u0026rsquo;s main product, an asset‑management system. The website was the old, established thing; the product was where the real value sat.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Keeping the site healthy while also improving the product\u0026rsquo;s experience was the remit.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The Hugo static site was maintained and enhanced — kept current and working — while UI/UX improvements and feedback fed into the primary asset‑management product at the same time. Splitting attention between a legacy site and the flagship product is mostly about not letting the old thing rot while you\u0026rsquo;re focused on the new one; both represent the company to someone, so both had to be kept decent.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e The website stayed current instead of quietly ageing, and the main product\u0026rsquo;s usability improved through steady, informed refinement — the kind that comes from actually using and thinking about the thing rather than redesigning it in one big swing.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/designed-a-time-management-and-reporting-system-that-88/","url":"https://engineer.company/portfolio/designed-a-time-management-and-reporting-system-that-88/","title":"Designed a time‑management and reporting system that remained in production use for years without significant modification.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e The team didn\u0026rsquo;t have a dependable way to manage time and report progress. Which usually means it\u0026rsquo;s happening in a scatter of spreadsheets and memory, and the reporting turns into a scramble at the end of each period rather than something that just falls out of how people work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Building a system for both that would actually last was the task.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A time‑management and reporting system was designed around how the team actually worked, rather than imposing some off‑the‑shelf process they\u0026rsquo;d route around. That\u0026rsquo;s the whole trick with internal tools — if it fits the real workflow, people use it; if it fights the workflow, they quietly abandon it and you\u0026rsquo;re back to spreadsheets. So it was built to match reality rather than an ideal.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e It stayed in production use for years without any significant modification. That\u0026rsquo;s the compliment you want for an internal tool — not that it was impressive, but that it just kept working and nobody ever needed to replace it. Something that survives years of daily use untouched was clearly built to fit.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/automated-team-collaboration-password-management-task-and-time-89/","url":"https://engineer.company/portfolio/automated-team-collaboration-password-management-task-and-time-89/","title":"Automated team collaboration, password management, task and time management, and built a semi‑automatic project‑showcase system, raising team productivity.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e A lot of the team\u0026rsquo;s operational work — coordinating, managing passwords, tracking tasks and time — was being done by hand, and manual coordination is a quiet tax: it\u0026rsquo;s never the thing you notice, but it steadily eats hours that could go somewhere better.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Automating that repetitive operational work was the goal.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The pieces that lent themselves to it got automated — team collaboration, password management, task management, time management — with a semi‑automatic project‑showcase system on top. The idea across all of it was to take the routine coordination off people\u0026rsquo;s plates so it ran itself, and let them spend the recovered attention on work that actually needed a human. The showcase system was the same instinct applied to something more visible: make presenting the work mostly automatic rather than a manual chore each time.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Operational efficiency went up and the team got more productive, because the routine coordination that used to need constant human attention now largely ran on its own. The time that was leaking into busywork went back into the actual work.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/integrated-a-company-wide-password-management-system-strengthening-90/","url":"https://engineer.company/portfolio/integrated-a-company-wide-password-management-system-strengthening-90/","title":"Integrated a company‑wide password‑management system, strengthening security and streamlining access control.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Credentials were being handled inconsistently — different people storing and sharing them in different, ad‑hoc ways — and that inconsistency is itself the security risk. It\u0026rsquo;s rarely a dramatic breach; it\u0026rsquo;s a password in a chat message, a shared login nobody rotates, the slow accumulation of small exposures.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Centralising the credentials and making them secure was the task.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e A company‑wide password‑management system went in, so there was one consistent, secure way credentials got stored and shared instead of everyone\u0026rsquo;s personal habit. The value of company‑wide is exactly that it\u0026rsquo;s not optional per person — a password manager only half the team uses barely helps, because the risk lives in the half that didn\u0026rsquo;t. So the point was to make the secure way the default way, everywhere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Security improved and access control got simpler and more consistent across the organisation. Once the credentials all live in one managed place, a whole set of small, boring exposures just stop being possible — which is most of what real‑world security actually is.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/drove-client-web-success-by-combining-custom-website-91/","url":"https://engineer.company/portfolio/drove-client-web-success-by-combining-custom-website-91/","title":"Drove client web success by combining custom website development and design with SEO, content strategy and copywriting.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Clients didn\u0026rsquo;t really want a website; they wanted the thing a website is supposed to do for them — to be found, to bring in customers, to actually work as a channel. A beautiful site nobody can find is a failure that looks like a success.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Combining the build and the growth side into one offering was the task, rather than handing over a site and wishing them luck.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The two halves were put together — custom website development and design on one side, SEO, content strategy and copywriting on the other — so a client got something that was both well‑built and actually discoverable. Those usually get treated as separate jobs, which is how you end up with a gorgeous site that ranks nowhere, or a well‑optimised site that\u0026rsquo;s unpleasant to use. Doing both meant the site was designed from the start to be found, not optimised as an afterthought.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Clients ended up with stronger visibility and more engagement — their sites working as genuine growth channels rather than online brochures. Building the thing and making it findable in one go is what turned a website from a cost into something that actually earned its keep.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/performed-data-recovery-across-a-wide-range-of-92/","url":"https://engineer.company/portfolio/performed-data-recovery-across-a-wide-range-of-92/","title":"Performed data recovery across a wide range of media — SD cards, HDDs, SSDs, RAID arrays, external drives and Mac systems.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e People turned up with storage that had failed or been damaged, and data on it they urgently needed back — and by the time someone\u0026rsquo;s carrying a dead drive into a shop, they\u0026rsquo;re usually past worried and into panicking. Photos, business files, the only copy of something that mattered.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Recovering their data, across whatever media they walked in with, was the job.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e Data recovery ran across pretty much every common storage type — SD cards, spinning HDDs, SSDs, RAID arrays, external drives, Mac systems. Each of those fails and gives up its data differently: an SSD is a different problem from a platter drive, a RAID array is a different problem again, and a Mac filesystem has its own quirks. So the work was as much about knowing the right approach for the specific medium as it was about any single technique.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Clients got critical data back from devices they\u0026rsquo;d already written off as gone, across every common kind of storage. There\u0026rsquo;s a specific relief on someone\u0026rsquo;s face when you hand back the drive with their files intact — that was the point of the work, and it happened across the whole range of media.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/portfolio/diagnosed-and-repaired-laptop-hardware-screens-hinges-keyboards-93/","url":"https://engineer.company/portfolio/diagnosed-and-repaired-laptop-hardware-screens-hinges-keyboards-93/","title":"Diagnosed and repaired laptop hardware — screens, hinges, keyboards, trackpads, motherboards and power — and resolved software issues across Linux, Windows and Mac.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Laptops came in with the full range of things that go wrong with laptops — cracked screens, broken hinges, dead keyboards, failing trackpads, motherboard faults, power problems — plus the software side, across Linux, Windows and Mac. Basically, whatever was wrong with it, it landed on the bench.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTask.\u003c/strong\u003e Diagnosing and fixing them reliably was the job — reliably being the operative word, because a laptop repair that doesn\u0026rsquo;t hold is just a delayed second visit.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAction.\u003c/strong\u003e The hardware was repaired end to end — screens, hinges, keyboards, trackpads, motherboards, power — which at the motherboard level is genuinely fiddly, close work, and the software problems resolved across all three operating systems. The diagnosis is usually the real skill: a laptop that won\u0026rsquo;t power on could be the charger, the board, or the battery, and the repair is only as good as the guess about what\u0026rsquo;s actually broken. So the care went into finding the real fault before touching anything.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResult.\u003c/strong\u003e Machines went back to their owners working and dependable, hardware and software both sorted. A repair that holds up is the only kind worth doing, and getting the diagnosis right first is what made these hold.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"}]}