Building from a problem I experienced at work gave me a useful starting point and a dangerous amount of confidence. I understood the operational pain of large media delivery, but that did not mean I understood a market, the right product boundary, or what anyone would pay for.
The origin is described in why I built a large-file transfer app. The larger lesson from building TeraAirlift is that firsthand experience supplies hypotheses, not validation. Everything after identifying the pain still has to be tested.
1. Personal conviction is not market evidence
My relevant background is founder-supplied and not independently verified: approximately 15 years across helpdesk, systems administration, cloud architecture, and infrastructure engineering, including systems-administrator work in an advertising and media environment. I dealt firsthand with large media deliveries, share links, slow or failed transfers, application allowlisting, access coordination, shared-storage ingestion, and shipped drives.
That experience helped me name the workflow accurately. It could not tell me how often other teams experienced it, which part they considered most expensive, who owned a budget, or whether they would change tools. One environment can reveal a problem without representing an industry.
The correction is to separate observations from assumptions. “I handled these tickets” describes my work. “This happens broadly,” “buyers rank it as a priority,” and “this product resolves it economically” require different evidence. I am not publishing customer counts, traction, or outcomes because those claims are not established here.
2. Validation should attack the riskiest belief
It is tempting to validate a technical product by asking whether people like its feature list. That tests politeness more than behavior.
For this product, the stronger questions concern the existing delivery route: what triggers a transfer, who participates, which step fails, what happens after failure, how status is reconstructed, when a drive is shipped, and which delay creates real operational pressure. The IT-cost worksheet turns those questions into tasks and handling time without pretending there is a universal cost.
Validation is still unfinished. Demos and workflow conversations can test whether the problem description, operator model, and product boundary fit. They do not by themselves prove willingness to pay, retention, or repeat usage. Those remain uncertainties rather than accomplishments.
3. Scope is a product decision
My first-SaaS instinct was to treat every adjacent need as part of the product. Large-file delivery quickly touches storage, identity, notification, packaging, billing, history, security review, and support. Trying to finish all of those at once would make the experiment harder to interpret.
The current boundary is narrower: TeraAirlift is a Windows-first desktop operations console for sending, receiving, tracking, and managing large files and folders. It focuses on delivery rather than long-term archive. Repository-supported capabilities include queue and progress visibility, ETA, cancellation and retry-friendly operations, history, diagnostics, recipient-controlled delivery, short-lived storage access, and SHA-256 integrity verification.
Windows-first was a scope choice grounded in the environment I knew. The current client uses .NET and WPF, while the architecture keeps core logic separate enough to support another client surface. Windows is current; Mac is coming soon. That is not a promise of a release date.
The narrow description also prevents accidental claims. The product does not guarantee throughput, exact retry semantics, availability, or an SLA. Some authentication, notification, storage-execution, packaging, and enterprise work remains staged or planned.
4. Very large files make implementation limits part of discovery
At terabyte scale, a configuration choice can become a product limit. Microsoft documents a maximum of 50,000 committed blocks in an Azure block blob and, for current service versions, a maximum block size of 4,000 MiB. The simple relationship is:
maximum payload = block count × block size
With 8 MiB chunks, 50,000 blocks cover only about 390.6 GiB. A setting that looks reasonable for a 20 GB file therefore cannot represent a multi-terabyte object without adjustment. Larger chunks reduce block count, while smaller chunks change request overhead and failure-recovery tradeoffs.
That example is architectural context, not a statement of TeraAirlift's exact production chunk policy, measured speed, or retry behavior. The general lesson is that an MVP for infrastructure software must test the edge implied by its promise. A “large-file” product tested only with small files has not tested its defining assumption.
5. Operations are part of the product
The visible transfer flow is only one layer. A desktop application raises distribution and update questions. Controlled delivery needs identity decisions, usage needs understandable records, and support needs diagnostics.
I treat those concerns as product behavior, not launch chores. The right MVP is not the smallest interface; it is the smallest test that includes risks capable of invalidating the idea.
6. Economics changed the design questions
The non-obvious pricing lesson was to model delivery separately from storage. Cloud storage is commonly priced by capacity over time. A delivery product also sends bytes back out, potentially to more than one recipient, and outbound data can be separately billed. Azure's published bandwidth page, for example, distinguishes free inbound transfer from tiered internet egress. Region, route, agreement, currency, and date all affect the actual amount.
That does not establish TeraAirlift's production provider, cost of goods sold, margin, or price. It changes the questions I have to answer: how long data is staged, how many downloads occur, which event is measured, what customers can forecast, and how usage becomes a comprehensible invoice. The deeper pricing analysis keeps its arithmetic explicitly illustrative.
Billing and pricing remain under evaluation. Current site language is limited to a 10 TB starting included allotment, with packages of any size and overage above that allotment. It is not a final price card, overage rate, meter, cadence, or billing specification. Details are confirmed on a demo.
7. Uncertainty is part of the status
The cleanest build-in-public update is a list of what remains unknown. I still need evidence about which teams feel the pain frequently enough to change, which workflow role owns the decision, which product boundary is sufficient, and which economic model is understandable and sustainable.
The current Windows client is available to download, and the transfer-time calculator can test a delivery window with your own inputs. Neither is proof that the business model is solved.
If I started again, I would write the evidence table before the feature backlog: what I observed personally, what the repository implements, what an official source supports, what a conversation suggests, and what is still an assumption. That separation has been more useful than trying to make an early product story sound complete.
Sources
- Founder/repository disclosure: Career history, workplace experience, and the lessons framed as personal observations are founder-supplied facts from the TeraAirlift research pack and have not been independently verified. Product status and capabilities are drawn from this repository's current product and site-status documentation.
- Microsoft Learn — Scalability and performance targets for Blob Storage — documented committed-block and block-size limits used in the illustrative chunk calculation.
- Microsoft Learn — Understanding block blobs, append blobs, and page blobs — block model and service-version qualifications.
- Azure — Bandwidth pricing — official inbound and outbound pricing structure; rates vary by route, region, agreement, and date.
