Once you know which layer you sit at, the next set of decisions is: at the layers below you, do you build or buy? Each build-vs-buy decision affects your margin, your operational complexity, your time to market, and your strategic flexibility. The five biggest decisions are below.
Decision 1: Run your own GPUs vs use an inference platform
This is the foundational decision and it has the biggest impact on your unit economics. If you run your own GPUs, you pay roughly $2.50 to $8 per hour per H100 depending on provider and contract length. A single H100 can produce roughly 60-200 FLUX images per minute depending on model variant and configuration, which works out to a marginal cost per image of about $0.001 to $0.005. If you use an inference platform like fal or Replicate, you pay roughly $0.005 to $0.05 per FLUX image depending on the variant and the platform. The platform markup is somewhere between 5x and 50x your raw compute cost.
At small scale (under, say, 100,000 generations per day) the platform markup is worth it. You do not need to manage your own GPU infrastructure, you do not need to handle autoscaling, you do not need to worry about cold starts or queueing or model loading. The operational simplicity is enormously valuable when you are still figuring out product-market fit. At large scale (millions of generations per day) the platform markup becomes a strategic problem, you are paying tens of thousands of dollars per day in margin to a third party that you could capture yourself with a few engineers and a GPU cluster contract.
The transition point varies but rough rules of thumb: under 50,000 generations per day, definitely use a platform. Over 1,000,000 generations per day, almost definitely run your own (or negotiate a custom contract with the platform). In between, it depends on your team's operational capability and whether the savings justify the engineering investment. The biggest mistake is to defer this decision past the point where it starts mattering, the longer you wait to migrate off a platform that has become economically painful, the more painful the migration is.
Decision 2: Use base models vs fine-tune your own
Most generative imagery products use off-the-shelf base models (FLUX, SDXL, SD3.5, etc.) and add value through workflow, User Experience (UX), and prompt engineering rather than through model customization. This is the right choice for 90% of products, base models are good enough, fine-tuning is expensive and operationally complex, and the product differentiation usually does not come from the model. There is, however, a 10% case where fine-tuning is the right call: if you are serving a specific vertical with idiosyncratic needs (architectural visualization, fashion ecommerce, medical imaging, anime production), and your customers will pay more for outputs that are clearly better at their specific use case, fine-tuning can produce a real moat.
Fine-tuning a model from an open base is feasible but not cheap. A serious fine-tune of FLUX dev or SDXL on a domain-specific dataset costs $10,000 to $200,000 in compute, requires a few weeks of an experienced ML engineer's time, and produces a model that is meaningfully better than the base model on your specific use case but slightly worse on everything else. The economic question is whether the customers in your vertical will pay enough of a premium for the better outputs to justify the development cost plus ongoing inference cost (because you are now hosting your own model, not using an off-the-shelf one).
LoRAs are a much cheaper alternative to full fine-tuning and the right answer for many cases. A custom LoRA trained on a few hundred carefully chosen reference images can shift a base model's behavior toward your domain without the expense of full fine-tuning. The trade-off is that LoRAs are less powerful than full fine-tunes, they can shift the model's style and aesthetic, but they cannot teach it fundamentally new capabilities. For a brand-style customization, a LoRA is right. For a domain-specific capability the base model lacks entirely, a fine-tune (or a different base model) is right.
Decision 3: ComfyUI on local hardware vs cloud workflow tools
This decision is specifically for products that need to run multi-step generation workflows (text-to-image followed by upscaling followed by ControlNet pose transfer followed by inpainting followed by face restoration, for example). The two main approaches are: run ComfyUI on your own hardware (either local or in your cloud), or use a hosted workflow tool like Krea, Flora, or fal's workflow API.
Local ComfyUI gives you maximum control and flexibility. You can write any workflow, use any model, integrate any custom node, and the unit economics are entirely yours. The downsides are operational: you have to maintain the ComfyUI installation, manage the model files (which can be hundreds of gigabytes), handle GPU management, update everything as new models are released, and build whatever user-facing interface you need on top. For a single artist or a small team, this is the right choice. For a multi-customer product, the operational overhead becomes significant.
Hosted workflow tools (Krea, Flora, fal's workflow API, Replicate's Cog framework) give you a managed environment where you describe the workflow in their format and they handle execution. The unit economics are worse than running it yourself, but you skip the operational complexity. The strategic risk is platform dependence, if the hosted tool changes pricing or removes a model you depend on, you have to migrate your workflows.
The pragmatic answer for most product teams: use a hosted workflow tool until you are large enough that the platform tax becomes painful, then migrate to local ComfyUI (or a custom inference stack) when the math flips. The transition is painful but not impossible, and the savings at scale can be 5-10x.
Decision 4: Multi-model strategy vs single-model commitment
Some products pick a single model and commit to it (Midjourney is the canonical example, they use only their own model). Other products offer access to many models (Krea, Flora, OpenArt all let users switch between FLUX, Ideogram, Imagen, and others). Each strategy has trade-offs.
Single-model commitment lets you build deeper around the model's specific quirks and capabilities. Your product can have User Interface (UI), prompt templates, workflow tools, and brand voice that are tailored to one model's strengths. Your users develop expertise in your specific model. The downside is that if a competing model gets dramatically better, you have to either migrate or watch your users leave. Midjourney has survived this risk by training their own model and improving it themselves; products that depended on a third-party model (like the early apps built on SD 1.5) often did not survive.
Multi-model strategy is the safer choice. You let users pick the model that fits their use case. You add new models as they launch and retire old ones as they become obsolete. The downside is that your product becomes a thin wrapper over commodity models, and the model providers can disintermediate you by going direct to users. Your differentiation has to come from workflow, UX, and brand rather than from any specific model.
There is no universally right answer. The strategic question is: what is your defensible position if FLUX 3 launches tomorrow and is dramatically better than the model you are currently optimized for? If your answer is 'we will switch to FLUX 3 within a week,' you are a multi-model product. If your answer is 'our model is good enough that the change won't matter to our users,' you are a single-model product (or you are wrong).
Decision 5: Run inference yourself vs let customers run their own
The final build-vs-buy decision is about who runs the inference. The two extremes are: you run inference for every generation (the 'Software as a Service (SaaS)' model, customers send you prompts and you return images) or customers run inference themselves (the 'self-hosted' or 'BYO model' approach, customers run the actual generation on their own machines and your product just provides the workflow tooling). Most products are at the SaaS end. A few notable exceptions exist: Pinokio, StabilityMatrix, and some enterprise products run inference on customer hardware.
The SaaS model has higher margins per customer but higher infrastructure costs and more legal exposure. The self-hosted model has lower margins per customer (you cannot charge for compute the customer is paying for) but much lower infrastructure costs and less legal exposure (the customer runs the model, so they are responsible for the outputs in most jurisdictions). For B2C and prosumer products, SaaS is almost always the right answer. For enterprise products serving customers who care about data sovereignty, regulatory compliance, or custom model integration, the self-hosted path is sometimes right.
Decision 6: hosted audio APIs vs self-hosted open models
Audio has its own build-versus-buy fork. A hosted API wins when volume is spiky, when you need current best-in-class voice quality, and, for music especially, when you need the vendor's licensing and commercial-use clearance, which you cannot manufacture yourself. Self-hosting an open model, MusicGen for music or an open speech model in the XTTS and F5-TTS lineage, wins on steady high volume, on data privacy for regulated or sensitive audio, and on control over latency and voice inventory. The hidden costs are real: GPU capacity you pay for whether or not it is busy, the inference engineering to keep it fast, and model-maintenance risk. When Coqui shut down in 2024 it left the widely deployed XTTS-v2 without an official maintainer, a reminder that an open model is a dependency you now own.