Scheduling & account access
EC2 and RDS scheduling, an account connection using IAM AssumeRole, and a savings dashboard.
PARKMYAWS / INDEPENDENT PRODUCTVisit the product ↗
Giving idle servers
a working week.
I’d used a tool that stopped our AWS environments overnight. When we cancelled it, the servers went back to running around the clock. I started building the alternative I wanted to use.
- My role
- Founder & solo engineer
- The product
- AWS resource scheduling
- Built with
- Laravel · Inertia · React · AWS
- Milestone
- Ready for beta, May 2026
01 / THE PROBLEMPaying for hours
Paying for hours
nobody needed.
We used ParkMyCloud to stop development and staging environments each evening and restart them the next morning. After an acquisition, the price increased and we cancelled.
The need hadn’t gone away. We gradually returned to leaving servers on. Custom scripts were an option, but they would still need maintenance and someone to own them.
I wanted a straightforward product: connect an AWS account, choose a schedule, and stop running compute through hours when nobody needs it.
The original problem, in my own words ↗EXPLORE THE IDEAA small change
A small change
to the working week.
Compare an always-on resource with an example weekday schedule. This demonstrates the product’s purpose; it isn’t a customer savings claim.
THE IDEA, IN ONE WEEK Illustrative example
00:0012:0024:00
Mon
Tue
Wed
Thu
Fri
Sat
Sun
40 running hours / week. 128 fewer idle hours
Example: weekdays, 09:00–17:00. Running hours only; actual costs depend on the AWS resources.
Visit ParkMyAWS02 / AN ENGINEERING DECISIONAccess is
Access is
part of the product.
A scheduling tool needs permission to act inside another company’s AWS account. Asking someone to connect that account is a substantial trust decision.
I chose IAM role assumption. The customer controls a role in their account; ParkMyAWS requests temporary credentials when it needs access. There are no permanent customer access keys to collect and keep.
This adds an onboarding step: the customer must configure the role and its permissions. I accepted that setup cost to keep account access explicit and scoped.
ONE DESIGN DECISION, UNDER THE HOODIAM AssumeRole
CUSTOMER’S AWS ACCOUNT
A role the customer controls.
The customer creates an IAM role. Its trust policy identifies the permitted AWS principal and requires the external ID assigned for that customer. Its permissions define which operations are allowed.
IAM role → trust policy + permissionsPARKMYAWS → AWS STS
Request a temporary session.
ParkMyAWS requests a session using the role ARN and the customer-specific external ID. AWS checks the trust policy before issuing temporary credentials. The external ID helps prevent cross-customer confusion; it is not a password.
sts:AssumeRole(RoleArn, ExternalId)TEMPORARY SESSION → CUSTOMER RESOURCES
Access with a time limit.
The session can perform only the operations its permissions allow. In the implementation I wrote about, credentials last 15 minutes. This avoids asking customers to hand over permanent access keys.
Temporary credentials · 900-second sessionSimplified explanation of my published integration approach. AWS reference ↗
03 / A PRODUCT DECISIONThe dashboard
The dashboard
I closed the tab on.
While building the product, I nearly spent several days planning an admin dashboard: customer management, usage analytics, support tooling.
At that point I had no customers. The first few could be handled with database queries and a terminal. I stopped planning the dashboard and kept the time for the core product.
“If a real customer wouldn’t notice it, it probably doesn’t need to exist yet.”My working rule, March 2026
Working in short evening sessions makes that choice tangible. Every feature competes with the next thing a user actually needs.
Read about the decision ↗04 / WHAT I TOOK TO BETAThe work around
The work around
the happy path.
Integration behaviour
My April progress update focused on testing resource state transitions and AWS API throttling before inviting beta users.
The rest of a SaaS
Billing integration, monitoring, error tracking, and the practical work around launching a product alongside a full-time job.
Built. Ready for beta.
Still something to prove.
On 1 May 2026, I wrote that scheduling and the savings dashboard were working, and announced that I was opening the beta. The next questions were about real use: would teams connect an account, understand the setup, and find the product useful?
That is the milestone this story documents. Building a working product and establishing its value to customers are different stages.
Read the May 2026 update ↗