ABOUT / LEHIGH VALLEY, PA
One machine.
It does not run one-handed.
Two-hand control is a real interlock on a real press: the thing will not cycle unless both controls are held at once. We have borrowed the idea because it describes this company exactly. Cloud City Computing is Kyle Adams and Dylan Fodor, and there is no job that goes through here with only one of us on it.
- Machines
- ONE
- Control banks
- TWO, ONE CLOCK
- What comes off
- YOURS TO RUN
The instrument
Both banks, one head, one cycle.
Your problem is fed in on the left as a blank. One tool head works it, and that head is fed by both banks at once: the interlock in the middle is green only while both are engaged. What leaves on the right is finished, warm, and no longer ours.
01
Scope
One real request, followed to where it stalls
02
Build
Slices, each in use before the next starts
03
Gate
Lint, build, browser tests, or it does not ship
04
Seal
Deploy on merge, rollback in one commit
05
Handover
Keys, accounts, and a runbook that is not for us
Stage
FeedScopeBuildGateSealHandover
Interlock
Both hands
Will not cycle
on one
Cloud City Computing · Lehigh Valley, PA
Operators: 2 · both write code · no third station
Cycle
18s, one clock
Every moving part states its own timing as a percentage of it. There is no animation delay anywhere in the block.
Banks engaged
two of two
Channel one on bank A and channel one on bank B are driven by the same keyframe, not by two that happen to match.
Stations
five, always
Scope, build, gate, seal, handover. The same five whether the job is one of ours or one of yours.
Output
yours to run
The workpiece is the only thing on the machine that changes colour, and it goes warm at seal.
Staggering the two banks is the obvious polish edit, and it would draw the opposite of the sentence beside it: two control banks running on separate clocks are two contractors invoicing the same client, which is the one thing this company is not.
The two operators
Whose hands those are.
01 / CTO
Kyle Adams
Founder & Chief Technology Officer
Kyle is the Founder of Cloud City Computing with deep experience across multiple IT roles. A Computer Science graduate from Moravian University, he is currently pursuing a Master's in Software Engineering from Drexel University. He works as a Full-Stack Software Engineer with a focus on DevXOps, bringing hands-on problem-solving expertise to every project.
LinkedIn Profile02 / COO
Dylan Fodor
Co-Owner & Chief Operating Officer
Dylan co-owns Cloud City Computing with Kyle, and he is a developer before he is anything else. A Computer Science graduate of Moravian University, he works on both the company's own products and the software it builds for clients. His focus is modernizing the systems a business already runs on, and putting language models inside them where they do real work rather than on top as a feature.
LinkedIn ProfileWhy this focus
Why documentation, workflow, and management software.
Kyle's background is DevXOps: the discipline of making the software behind a team's own process, its tooling, its deploy pipeline, its internal systems, as solid as the product it ships. Dylan's day-to-day work as an applications developer sits on the other side of the same problem: the systems a business runs its real operations on, where a quiet failure costs money before anyone notices. Between the two of us, we kept hitting the same pattern in different rooms: teams running their real business on a spreadsheet, a shared inbox, or a wiki nobody trusts, because nobody ever built them something better.
Documentation, workflow, and management software are the three shapes that pattern keeps taking. Documentation is where a team's knowledge either stays findable or scatters across chat threads. Workflow is the handoff between systems that people currently do by hand: retyping data, chasing approvals, copying between tools that were never meant to talk to each other. Management software is the system of record a team runs its operations on, and it fails quietly when nobody owns keeping it consistent. We build Cloud Codex and quartermaster to solve exactly these three problems for ourselves first, which is why we can point to them as evidence rather than a pitch when we build the same kind of software for a client.