Robert Entwistle

Product and Technology Leader | Product Direction · Architecture · Delivery

I work out what should be built, make the technical decisions, and stay involved until it works in production.

I work between customers, product, and engineering, turning unclear problems into a practical direction and helping teams move from idea to working software.

I have done this at Apple and in several startups, combining product judgment with enough technical depth to shape the architecture and build when needed. INSEAD MBA.

8 → 1systems consolidated
50M+records in production
0downtime on cutover
$7K/mohosting costs cut

Selected outcomes

Outcome 01

Consolidated 8 systems into one multi-tenant platform

Recognized that maintaining 8 overlapping systems was consuming budget without creating new value, then made the case to replace them with one shared platform.

Business problemEight systems with significant functional overlap were maintained separately, creating recurring costs, duplicated work, and increasing complexity across integrations and reporting.
What I didDetermined that the larger problem was not any individual system, but the cost and complexity of maintaining all 8 independently. Made the case for consolidation, then led the development effort, building a Laravel backend as the single source of truth and a React and TypeScript frontend, working with team and contractors on parts of the delivery. Added load-balanced infrastructure and CI/CD so the new platform could support future growth.
Result
Replaced 8 systems with one, eliminated redundant maintenance, retired 3 servers, and completed the switchover with zero downtime. The platform now handles more than 50 million product records and thousands of daily requests.
LaravelReactTypeScriptMantineJWTOAuthAWSCloudFrontCI/CDGitHub Actions
Outcome 02

Built a self-service product from zero to one

Observed clients calling support for routine campaign changes and proposed a self-service portal instead of continuing to expand the manual support model.

Business problemThe platform ran in a costly self-hosted datacenter, while clients had to contact support for every campaign change and had no direct access to performance data.
What I didJoined client calls and site visits as Head of Technology and saw that routine campaign setup and reporting depended heavily on support staff. Proposed a self-service portal, secured CEO and executive buy-in, and migrated the platform to AWS to create the foundation for it. Worked alongside one other developer to take the portal from concept to production, contributing directly when needed and extending the existing mobile apps to support the new capabilities.
Result
Cut infrastructure costs by more than $7,000 per month and replaced a recurring support workflow with a self-service product that clients could manage directly.
AWSREST APIsiOSAndroidCloud Migration
Outcome 03

Reduced a day-long report to about 10 minutes

Automated a reporting process used by at least 50 product managers that consumed nearly a full day each month, then used the same data to identify underserved vehicle segments.

Business problemAt least 50 product managers each spent nearly a full day assembling recurring reports, followed by additional manual work from the content team.
What I didSpecified and built a tenant-isolated ETL and reporting pipeline using AWS Athena and Parquet, choosing an on-demand architecture because each report ran only once or twice a month and did not justify an always-on warehouse. After automating the original process, proposed a second phase that cross-referenced product coverage with vehicle population data to show where the client was underserved.
Result
Reduced each reporting process from nearly a full day to roughly 10 minutes, then delivered a coverage-by-population view that created additional value beyond the original request.
AWS AthenaParquetETLData PipelinesReporting DashboardsAPIsReact

How I work

From customer problem to shipped system

1

Start with the customer

Who's the customer, how will they actually use it, and why does this need to exist at all, before any spec gets written.

2

Make the tradeoffs explicit

Choose an approach that fits the team, budget, and risk tolerance, and lay out what you're trading off, not just what you're building.

3

Get people on board

Turn the plan into something leadership and stakeholders can say yes to, whether that's a CEO and investors or an engineering team.

4

Build it, in whatever form the problem needs

Solo when that's the fastest path, with a small team when it needs more hands, or handed off entirely when that's the right call, and technical enough to know the difference.

Experience

Independent Product & Technology Consultant2025-Present

Builds AI prototypes, modernizes client applications, and advises on product and architecture decisions. Recent work includes Bedrock-based AI tools, ETL automation, multi-tenant Laravel architecture, and React platform modernization.

Senior Software Engineer, Harbor Compliance2024-2025

Solved platform-level data, integration, migration, and security problems for a government compliance SaaS product, including a database fix that avoided a $3,000 monthly Azure upgrade and reduced recurring support issues.

Technical Product Manager, dPivot2018-2024

Owned product and technical direction for a data and media SaaS platform, from consolidating 8 systems into one multi-tenant platform to delivering custom client products, automated reporting, and scalable infrastructure.

Head of Technology, Trust Payments / Mobilize Systems2014-2018

Led product and technology initiatives for a loyalty SaaS platform, including securing executive backing for a self-service client portal, delivering it with a small team in about 6 months, and migrating the platform from a legacy datacenter to AWS.

Earlier Experience: Apple, BigMachines, and Startups

Worked across enterprise systems, product delivery, client engagements, data integration, reporting, and education technology, combining technical implementation with stakeholder and executive communication.

The roles where I do my best work

I do my best work when there is a real problem, no obvious answer, and someone needs to understand both the customer and the system well enough to decide what should happen next.

I fit best between product, architecture, and delivery. That meaas working out what should be built, making the technical decisions, and staying involved until it works in production.

Get in touchrobert@entwistle.tv