Model fallback and AI pricing strategy are not engineering details. They are product decisions with direct consequences for user trust, retention, and revenue sustainability. Getting them wrong does not just create technical debt; it creates business risk.

This article walks through a five-layer framework derived from real production experience building AI-powered products, covering how intelligent routing, fallback architecture, financial observability, value-based pricing, and guardrails work together as a coherent product and engineering strategy.

Building an AI product and looking for experienced partners? Explore Cheesecake Labs’ AI development services

Why most AI products fail before they scale

The gap between a working AI prototype and a reliable production product is wider than most teams expect. Industry data makes this visible: roughly 40% of LLM outputs, according to OptimusAI, are not consistently reliable in production environments, and around 95% of AI pilots, according to Typedef.ai’s study “13 LLM Adoption Statistics”, stall before reaching scale — not because the models underperform, but because the surrounding infrastructure is not designed to sustain real usage conditions.

The root cause is almost always structural. Teams build features that work in isolation but lack the operational layers needed to handle cost variability, model failures, and unpredictable user behavior at scale. When those layers are absent, AI products become expensive to operate, fragile under load, and impossible to price sustainably.

The solution is not a better model. It is a better architecture — one that treats model fallback and pricing as first-class product concerns from day one.

The five-layer framework: from feature to reliable product

The framework below reflects how production AI systems need to be structured when reliability, cost control, and user trust are non-negotiable requirements. Each layer addresses a specific failure mode that appears consistently across AI product development.

“We don’t sell tokens. We sell reliable solutions. The architecture must reflect that.”

Layer 1: Intelligent model routing: the 20x cost problem

The single most impactful architectural decision in an AI product is also the most commonly overlooked: not every task requires the same model.

In practice, cost differences between the cheapest and most expensive commercially available models can reach 20x or more. Using Claude Sonnet 4.5 at $3.00 per million input tokens for every request — including simple summaries, data extractions, and short classifications — when a model at $0.15 per million tokens handles those tasks equally well is not a quality decision. It is a marginal decision made by default, and it is unsustainable.

A well-designed routing layer dynamically assigns each task to the most appropriate model based on complexity, balancing three variables simultaneously: cost, latency, and output quality.

A real-world routing policy looks like this:

• Default model (80% of tasks): A lightweight, fast model handles summarization, extraction, and tool selection for simple interactions and basic Q&A. Cheap, fast, and reliable for well-scoped tasks.
• Premium model (upgrade path): A more capable model is invoked when task complexity crosses a defined threshold — multi-step planning, complex tool orchestration, reasoning-intensive automation workflows.
• Economic fallback: An alternative provider’s model enters when the primary infrastructure fails or when budget thresholds are reached.

Latency compounds the cost argument. Higher-capability models are slower — not marginally, but meaningfully. A user waiting 30+ seconds for a response to a simple request will not stay. They will reload the page, assume the product is broken, and lose confidence. Routing decisions affect both the income statement and the product experience.

At 20x cost variation, intelligent routing is not an optimization. It is a product survival decision.

Layer 2: Model fallback and redundancy: designing for inevitable failure

Rate limits, server errors, and infrastructure outages are not edge cases. They are operational facts for any AI product running in production. The architecture question is not whether failures will happen — it is whether the product recovers automatically and transparently, or exposes failures directly to users.

Most developers design fallbacks like a ladder: if Model A fails, try a slightly better Model A. In a true production environment, this can lead to outages.

A production-grade fallback architecture is not a linear list; it is a matrix. You must solve for two different types of failure simultaneously: loss of service and loss of quality.

• Infrastructure Diversity: This solves for connectivity. If Provider A returns a 5xx or a regional outage occurs, your architecture must immediately jump to an entirely different infrastructure (Provider B or a self-hosted instance).
• Model Tiers: This solves for logic. If the primary model (low-cost) fails to parse a complex prompt or hits a token limit, you escalate to a “Frontier” model (high-capability) to maintain the quality of the output.

A robust system operates on a defined execution order that balances these two pillars, for example:

1. Primary model (default, lowest cost, primary provider)
2. Upgraded model (same provider, higher capability)
3. Legacy model (same provider, maintained for fallback)
4. Cross-provider model (alternative infrastructure, eliminates single point of failure)
5. Last-resort model (emergency fallback, minimal cost)

When a model returns an HTTP 429 (rate limit) or a 5xx server error, the system triggers a Circuit Break pattern. The failing model enters a quarantine window, starting at 10 minutes and utilizing Exponential Backoff in production-grade systems, during which the system automatically routes requests to the next model in the sequence. After the cooldown period, the original model is retested automatically, since many failures are transient.

Critical distinction: not every error type warrants a fallback. When input exceeds a model’s context window, routing to a smaller model will produce the same failure — smaller models have narrower context limits, not wider ones. In these cases, the correct response is a clear user-facing message with a meaningful next step, such as opening a new conversation.

Multi-provider architecture adds a qualitatively different layer of resilience. By distributing across two independent infrastructure providers (for example, AWS Bedrock as primary and Groq as fallback), the system eliminates its single point of failure. If one provider goes down entirely, traffic shifts automatically without any user interruption.

From a product perspective, fallback is also a pricing conversation. When model pricing changes without notice — which LLM providers do regularly — teams without fallback architecture face a binary choice: absorb the cost increase or break the product. Teams with a tested fallback chain can absorb that disruption in minutes.

Layer 3: Financial observability: you cannot price what you cannot measure

One of the most consequential gaps in early-stage AI products is the absence of cost visibility at the operational level. LLM-based systems have dynamic, per-token pricing across multiple models and providers. Without deliberate tracking, costs accumulate invisibly until an invoice makes the problem undeniable.

Financial observability means tracking cost not just per API call, but per operation type — per feature, per workflow, per interaction. Every distinct product action should have its cost attributed individually: chat messages, task planning, tool selection, automation runs, and report generation.

This granularity transforms how product and business decisions get made.

A real consequence of implementing this: When a team enabled operation-level cost tracking on an automation feature, they discovered the feature was costing $4 to 10 per execution — significantly more than the monthly subscription price they had been planning to charge.

Without that data, they would have launched a feature that actively eroded margins. With it, they redesigned the pricing model, shifting from monthly to weekly billing, to align the user-facing price with the actual delivery cost.

What to track per operation:

• Input and output token counts
• Model used and provider
• Operation type and feature context
• Estimated cost per call
• Number of agent turns to complete the task

Infrastructure consideration: reporting queries should not compete with production traffic. A practical implementation logs token usage to a primary operational database (for real-time tracking) while syncing to a dedicated analytics replica on write. This ensures reporting never degrades the user experience.

Prompt caching adds a complementary cost reduction lever. For long, static, frequently repeated prompts — such as those describing available tools, system configurations, or data models — caching can reduce token costs by up to 90% by serving stored results rather than re-invoking the model. This is particularly valuable for automation workflows where the same system context is sent repeatedly across different user sessions.

Financial observability is not just cost control infrastructure. It is the data layer that makes a pricing strategy possible.

Layer 4: AI pricing strategy: charge for value, not for tokens

How an AI product prices externally should reflect how it is structured internally. And the most common structural mistake is pricing based on token consumption.

Token-based pricing has a predictable failure mode: it transfers the complexity and unpredictability of model economics directly to the user. Non-technical audiences — which is most end users — cannot evaluate whether a 2,000-token response represents good value. They do not know what a token is, and they should not need to. Exposing that complexity creates friction, reduces adoption, and misaligns perceived value with actual product utility.

Value-based pricing replaces token consumption with task completion as the billing unit. Users pay for what they receive: outcomes, reports, automations, and summaries.

Real cost data from production systems illustrates the pricing math:

For a task with 2,000 input tokens and 500 output tokens:

• Claude Sonnet 4.5: ~$0.0135 per task
• Claude Haiku 4.5: ~$0.0045 per task (3x cheaper)
• GPT-OSS 120B via Groq: ~$0.0006 per task (22x cheaper)

An automation that runs once per business day, using a premium model, costs approximately $5-10 per execution; $100-200 per month at full usage. That unit economics reality should drive how the feature is packaged and priced before launch, not after users start complaining about unexpected charges.

Practical pricing principles for AI products:

• Price by task, outcome, or workflow completion, not by token count or API call
• Build in a 20-30% cost buffer to absorb model pricing changes without margin erosion
• Review pricing quarterly and whenever a provider updates its rate structure
• When users can select model quality (fast vs. best), communicate the cost difference explicitly at the point of selection
• Consider frequency packaging: weekly billing for high-cost daily automations often converts better than monthly billing at the same total price

The core principle: the price of a feature should reflect the value it delivers — the task resolved, not the cost of the infrastructure that processed it.

Layer 5: Guardrails and trust: where safety becomes product quality

Guardrails are the layer that makes AI products safe to use in production — for users, for the business, and for compliance purposes. They operate in two directions simultaneously.

Input guardrails intercept problematic requests before they reach the model. This includes filtering out PII that should not be sent to external LLM providers, blocking queries outside the product’s defined scope (avoiding unnecessary token spend on out-of-scope requests), and enforcing rate limits at the user and organization level to prevent margin erosion from power users.

Output guardrails validate what the model returns. This means checking for policy violations, inappropriate content, data that should not be surfaced, and brand consistency failures. A guardrail that catches a competitor’s name appearing in a brand’s customer-facing chatbot response is not a minor technical feature — it is reputation protection.

A second model call can serve as an automated self-check: a separate invocation that evaluates response quality and compliance without the context of the original conversation. This LLM-as-a-judge pattern enables scalable quality auditing that would be impossible to do manually at any meaningful volume.

Guardrail telemetry is as important as the guardrails themselves. Teams should track:

• Block rate by reason (safety violations vs. budget limits vs. scope violations)
• False positive rate (legitimate requests incorrectly blocked)
• Context limit hits (users running into conversation length ceilings)
• Data leak incidents

The user-facing side of guardrails matters as much as the technical implementation. When a limit is reached, the product should explain what happened and offer a meaningful alternative — not show a generic error. “You’ve reached the context limit for this conversation. Open a new chat to continue” is a product experience. A blank screen or an unexplained error is a trust problem.

Budget guardrails also create the conditions for transparent pricing. When users understand that each interaction costs a defined number of credits, and when limits are communicated clearly before they are reached, the pricing model feels fair rather than arbitrary.

The performance vs. quality trade-off: what teams rarely discuss honestly

There is a real and unavoidable trade-off in AI model selection that product teams often avoid: higher-quality models are slower, and that slowness is not accidental — it is structural.

When a model enters “thinking mode” — the extended reasoning process that produces higher-quality outputs — it is, by design, taking more time. The quality is inversely proportional to the speed of token generation. Asking a team to find a model that is simultaneously the cheapest, fastest, and highest-quality is asking for something that does not exist today.

This creates a genuine product decision: which tasks justify the latency cost of a premium model, and which tasks are better served by a fast, cheap model that responds in under two seconds?

The answer is rarely “use the premium model for everything.” The answer is intelligent routing, tested and calibrated against real usage data — starting with the best model available, stepping down until quality degrades unacceptably, and locking that configuration in code.

The teams that get this right do not debate model selection philosophically. They instrument their systems, measure outcomes, and let data drive the routing policy.

Common anti-patterns that undermine AI product sustainability

The same failure modes appear repeatedly across AI product teams, and most of them are architectural decisions made too early or not made at all.

Avoiding these patterns at the architecture phase is dramatically cheaper than refactoring around them after a product is in the hands of paying customers.

Key Takeaways

• Model fallback is a product decision, not just a reliability pattern, but it directly determines whether pricing is sustainable when infrastructure fails or changes
• Intelligent routing at 20x cost variance is the difference between a product with healthy margins and one that bleeds token costs at scale
• Financial observability at the operation level is what makes pricing strategy possible — without it, teams price on assumptions and discover the reality in their cloud bills
• Value-based pricing outperforms token-based pricing for adoption, retention, and margin sustainability across every user segment
• Guardrails protect brand trust and compliance, not just infrastructure costs, and their UX matters as much as their technical implementation
• Robust architecture is not just about reducing cost: it is a lever for revenue, retention, and long-term product viability

Building a Private AI Notetaking Platform That Powers Secure Workflows: Knapsack case

Cheesecake Labs partnered with Knapsack to re-architect their AI platform — evolving it from a fully local prototype to a hybrid, compliance-first system ready for enterprise scale.

“We couldn’t have solved some of the complex problems to deliver this product without the support of Cheesecake Labs’ team.”

Mark Heynen — Co-Founder & Chief Product Officer, Knapsack

Build AI products that last

The gap between an AI prototype and a production-grade AI product comes down to decisions made about model fallback, routing, observability, and pricing—long before most teams even consider them.

At Cheesecake Labs, we help product teams make these decisions right from the start by building AI systems that are resilient, cost-aware, and designed to scale sustainably.

The post 17000 characters appeared first on Cheesecake Labs.

In this post, we’ll show you how to create a Stellar smart contract and discuss how best to use Stellar’s Soroban and its flexible features.

Table of Contents

1. asd
2. asd
3. asd
4. asd
5. asd

Bond tokens

• asd
• asd
• asd
• asd
• asd

In finance, bonds are securities in which the issuer owes the holder a debt. After a period of time, the bond issuer pays all holders the bond’s value and the interest rate.

This is beneficial for the users, who profit from the purchase of bonds, and for the issuer, who can conduct business using the money used to buy the bonds before they’re paid out.

For our use case, we will treat the bonds as tokens, which users can buy and trade.

ERC-20 Tokens

The ERC-20 is a popular standard of Fungible Tokens used to ensure that each token is created using the same methods as another token.

It is an essential tool for interoperating with other contracts because it allows integration with the token without needing to know the details of its implementation.

For our use case, it will represent our bond token and the payment token, which will be used to buy bonds and pay debts.

The Soroban interface based on the ERC-20 token standard can be found in the official Soroban documentation. We are using this compiled interface, which can be found in the Soroban examples repository.

Writing the smart contract

Before we begin, let’s take a look at the logic of our smart contract.

There are two types of users: the Admin, who manages the contract, and the Users, who can buy the bonds and cash out when allowed.

The administrator is responsible for managing the contract and determining when a bond can be bought, how long it will appreciate in value, and when users can withdraw their money.

Some extra management actions are also allowed, like managing which users can buy the bonds or pausing purchases temporarily. Finally, the admin can also withdraw the money received to pay the bonds.

The users can perform two actions — purchasing a bond and cashing out. They can only perform these actions can in the periods set by the admin and if they have the necessary authorization.

The appreciation of the bond occurs over a period determined by the administrator, bound by the start date and the end date. The purchase period of the bond is not directly linked to this period and can occur at different intervals.

Contract attributes like which tokens will be used, interest rate, interest type, and interest time interval are customizable and are set at initialization. We will discuss this in more detail in the following sections.

Initialization

The initialize function sets the contract attributes right after its deployment. We won’t go too deep into its implementation, but it is essential to understand the parameters it receives.

impl BondTrait for Bond {
	...
	fn initialize(
      e: Env,
      admin: Identifier,
      payment_token_id: BytesN<32>,
      bond_token_name: Bytes,
      bond_token_symbol: Bytes,
      bond_token_decimals: u32,
      price: i128,
      fee_rate: i128,
      fee_days_interval: u64,
      fee_type: InterestType,
      initial_amount: i128,
  ) {
		...
	}
}Code language: Rust (rust)

Some considerations about these parameters:

Next, we will dive a little deeper into some of the core components of the contract, starting with the buy.

Buy bonds

impl BondTrait for Bond {
	...
	fn buy(e: Env, amount: i128) {
	    if read_state(&e) != State::Available {
	        panic_with_error!(&e, Error::NotAvailable)
	    }
	    if !check_user(&e, &(e.invoker().into())) {
	        panic_with_error!(&e, Error::UserNotAllowed)
	    }
	    increase_supply(&e, amount);
	    // Total will be the Bond amount multiplied by Bond price
	    let total = current_price(&e) * amount;
	    ...
	}
}Code language: Rust (rust)

For a user to be able to buy a bond, the purchase must be available, and the administrator must authorize the user. If the user satisfies these requirements, the supply (the amount of bond sold) increases by the amount the user intends to buy.

After this, it is necessary to calculate the bond’s current price. This is because the bond starts at a certain price but gets more expensive as time passes. Let’s look at the current_price function that performs this calculation.

fn current_price(e: &Env) -> i128 {
    let mut end_time = read_end_time(&e);
    let now = e.ledger().timestamp();
    // If the end date has not passed yet
    if now < end_time {
        end_time = now;
    }
    let initial_price = read_price(&e);
    // Calculates the amount of time intervals that have passed
    let time = (end_time - read_init_time(&e)) / read_fee_interval(&e);
    // If no time interval has passed, the price does not change
    if time == 0 {
        return initial_price;
    }
    let fee_type = read_fee_type(e);
    match fee_type {
        InterestType::Simple => {
            return initial_price + (initial_price * (time as i128) * read_fee_rate(&e)) / 1000;
        }
        InterestType::Compound => {
            let fees = 1000 + read_fee_rate(&e);
            return initial_price * (fees.pow(time as u32)) / 1000_i128.pow(time as u32);
        }
    }
}Code language: Rust (rust)

Here we need to calculate how much time has elapsed between the bond’s start date and now unless the end date has already passed, in which case, we will calculate the time between the start date and the end date.

With the time calculated, we need to determine how many time intervals have passed. For example, if our interval is one week, and 40 days have passed since the starting date, this value will be equal to 40 mod 7 = 5. In Soroban, all divisions are integer divisions, so we don’t have to worry about the modulo.

Our contract gives the flexibility to apply simple or compound interest, depending on the choice made at initialization. The calculation for each type of interest follows the standard logic of the mathematical interest formula, except for the 1000 factor. The factor 1000 added in each of the operations neutralizes our interest rate, which is multiplied by this value.

impl BondTrait for Bond {
	...
	fn buy(e: Env, amount: i128) {
	    ...
	    // Total will be the Bond amount multiplied by Bond price
	    let total = current_price(&e) * amount;
	    let invoker: Identifier = e.invoker().into();
	    transfer_from_account_to_contract(&e, &read_payment_token(&e), &invoker.clone(), &total);
	    transfer_from_contract_to_account(&e, &read_bond_token_id(&e), &invoker.clone(), &amount);
	}
}Code language: Rust (rust)

impl BondTrait for Bond {
	...
	fn withdraw(e: Env, amount: i128) {
	    check_admin(&e, &Signature::Invoker);
	    if read_state(&e) == State::CashOutEn {
	        panic_with_error!(&e, Error::AlreadyCashOutEn)
	    }
	    transfer_from_contract_to_account(
	        &e,
	        &read_payment_token(&e),
	        &e.invoker().clone().into(),
	        &amount,
	    );
	}
}Code language: Rust (rust)

impl BondTrait for Bond {
	...
	fn en_csh_out(e: Env) {
	    check_admin(&e, &Signature::Invoker);
	
	    let state = read_state(&e);
	    if state != State::Available && state != State::Paused {
	        panic_with_error!(&e, Error::NotAvailable)
	    }
	
	    // Check if end time has passed
	    if e.ledger().timestamp() < read_end_time(&e) {
	        panic_with_error!(&e, Error::EndTimeNotPassed)
	    }
	
	    // Check if the contract has the amount of payment tokens to
	    // pay the users
	    let amount_payment = current_price(&e) * read_supply(&e);
	    let contract_balance = token_balance(
	        &e,
	        &read_payment_token(&e),
	        &Identifier::Contract(e.current_contract()),
	    );
	
	    if contract_balance < amount_payment {
	        panic_with_error!(&e, Error::NotEnoughTokens)
	    }
	
	    write_state(&e, State::CashOutEn);
	}
}Code language: Rust (rust)

After the conditions are met, the contract state is changed to allow cash out.

Cash out

The cash out is performed by reading the user’s balance and checking how many bonds they have on their account. The amount of payment tokens transferred from the contract to the user’s account is the number of bonds they own multiplied by the bond’s current value.

impl BondTrait for Bond {
	...
	fn cash_out(e: Env) {
	    if read_state(&e) != State::CashOutEn {
	        panic_with_error!(&e, Error::NotCashOutEn)
	    }
	
	    let invoker: Identifier = e.invoker().into();
	
	    // Get the user Bond Token balance
	    let bond_balance = token_balance(&e, &read_bond_token_id(&e), &invoker.clone());
	    // Calculates amount of payment token
	    let total_payment = bond_balance * current_price(&e);
	    // Decrease supply
	    decrease_supply(&e, bond_balance);
	    // Transfer amount of payment tokens from contract to user
	    transfer_from_contract_to_account(
	        &e,
	        &&read_payment_token(&e),
	        &invoker.clone(),
	        &total_payment,
	    );
	    // Burn all the Bond tokens from user
	    burn_token(
	        &e,
	        &read_bond_token_id(&e),
	        &Signature::Invoker,
	        &invoker,
	        &bond_balance,
	    );
	}
}Code language: Rust (rust)

This implies that no matter how much the user paid for the bond, they will always get their money back at a higher price. For example, if user A bought 100 bonds and user B bought 100 bonds a few months later, both users will receive the same number of payment tokens at the cash-out.

The key difference is that the profit of user A will be higher as they paid less for the bond initially than user B.

After transferring the payment, the user’s bonds are burned. This transaction is only possible because the current contract is the admin of the bond token contract.

Learn more about the blockchain with Cheesecake Labs

This post has outlined the core components of a bond sales contract. If you would like to explore the rest of the functions in more depth, you can take a look at the source code.

You can learn more about the Stellar network, cryptocurrency wallet development, and the basics of blockchain on the Cheesecake Labs blog. And sign up for the Cheesecake Labs newsletter to get the latest updates delivered to your inbox.

As a Stellar Integration Partner, Cheesecake Labs is an excellent choice to help you bring your ideas for blockchain projects to life.

Get in touch and tell us about your project!

The post How to use Stellar’s Soroban to write a bond smart contract appeared first on Cheesecake Labs.

But first, let’s start with the fundamentals. 

What is blockchain?

Blockchain is, in essence, a ledger technology. It keeps a record of, well, whatever you want. And it holds that record using tech that is extremely secure, flexible, transparent, and straightforward.

It can help to visualize a blockchain as a row of wooden blocks lined up in a row. Let’s say that each time you want to add a new wooden block to this row, you also want to preserve the order that the blocks are already in. Each time you add a new block to the row, you take a marker and draw a unique image on the seam where the last block and the new block meet. When you separate the two blocks, half of the image remains on each block. 

If each block has part of an overlapping image connecting it to its adjacent blocks, then you won’t be able to remove or replace any of these blocks. You’ll instantly recognize that they’ve been tampered with because the images won’t make sense anymore. 

In essence, this is how blockchain works. It’s also where the name comes from. You can use blockchain to keep track of different file versions, people walking into a building, medical records, and financial transactions. 

Not only can you not rearrange the data stored in a blockchain (making it immutably chronological), but you can also trust that it is immensely secure. Blockchains are very well encrypted and can be centralized for the private sector or decentralized for the public sector. 

What are blockchain payment systems?

That brings us to blockchain payment systems. Blockchain payment systems are just one of the applications of blockchain technology. In this instance, a new block is added to the blockchain every time a transaction takes place. 

Since these blocks can’t be rearranged, edited, or removed, you can have nearly total confidence that the record of transactions is accurate. This is one reason that cryptocurrencies like Bitcoin are trusted. While you don’t have physical money to hold onto, the Bitcoin blockchain proves, immutably, that you have the money your account says you do. 

You can, of course, use blockchain payment systems to support a cryptocurrency. But you can also use them in other financial sectors. There’s no reason why Venmo, Visa, PayPal, or even your local bank can’t use blockchain to keep a record of transactions. In fact, doing so could be an improvement, reducing the chances of fraud and error. 

Examples of blockchain payment systems

• Bitcoin. Bitcoin is synonymous with blockchain technology, and that’s because Bitcoin is the progenitor of blockchain. The Bitcoin blockchain keeps a record of every new Bitcoin created and follows the journey of that Bitcoin from one individual to the next. 
• Ethereum. Similar to Bitcoin, Ethereum is a cryptocurrency that relies on blockchain. However, Ethereum benefited from coming after and has incorporated interesting features like executable code, improved security, and programmatic contracts.
• Stellar. Stellar is a unique blockchain payment system. It allows you to easily create your own form of stablecoin (a cryptocurrency that doesn’t fluctuate wildly in price) and distribute it however you like. You can use this to create cryptocurrencies tied to fiat currency, used within a specific business (“Google Coin” does not currently exist!), or just a tradable asset for you and your friends. 
• Mastercard Blockchain. Mastercard has developed Start Path, a fast-track solution for businesses and organizations to create their own cryptocurrency and blockchain solution. 

How to create a blockchain payment platform: You have two options

As you can see from the examples above, blockchain payment platforms are no longer just for “diamond hands” crypto fans or tech savants. There are many uses for blockchain technology, and any business (or motivated individual) can put the tech to use. 

Today, there are two routes you can go down if you want to create your own blockchain solution. 

Build your own cryptocurrency

The first option that probably comes to mind is creating your own unique cryptocurrency. After all, it’s the route that most have gone down in blockchain’s infancy. Building your own cryptocurrency and blockchain to back it up is the traditional route, primarily because blockchain technology is still finding its footing. 

To do this, you need to either create a blockchain and cryptocurrency from scratch or create a new crypto token based on an existing cryptocurrency/currency. 

Then, you need to ensure that your crypto/blockchain solution is secure, compliant, and tradable with existing cryptocurrencies (assuming that is your goal). Unsurprisingly, this can be extremely difficult and can require an abundance of serious development talent. 

Use an existing cryptocurrency

Alternatively, you could just create a blockchain payment system that works with an existing cryptocurrency. It’s no surprise that this is a far easier solution, though it does mean you’ll have less control over the cryptocurrency. And your blockchain will need to conform to the crypto rather than the other way around. 

If this is the option you choose, you can compare it to a platform like PayPal or Venmo. Neither created its own currency and for a long time, neither even offered traditional banking services. They were just a means of quickly sending money over the internet. 

Blockchain payment systems can work similarly. They can act as a middleman for cryptocurrency, adding unique features that make it easier and more efficient. 

Steps to implement blockchain payment processing in your enterprise

Step 1: Project planning

The first step in launching your blockchain payment processing system is to plan out your project. 

Are you going to create a new blockchain and/or cryptocurrency from scratch? Or are you going to make an overlay/fork of an existing solution?

Is your platform going to be web-based, or will it be launched as a mobile app? Maybe a combination of the two is right for your business?

Step 2: Onboard a development team

Once you’ve got an idea of how you want to proceed, you’re going to need a development team. Development teams for blockchain payment systems can be challenging to find, especially reliable ones because the technology is new. 

Additionally, the newness of the tech means that you won’t just have a hard time finding knowledgeable talent, but capable talent, too. In total, you’ll need to find:

• A project manager
• An IT architect
• Blockchain developers
• Web developers (if building a web app)
• iOS and Android developers (if developing a mobile app)
• Testers
• DevOps engineers

Or partner with a team of development experts

If you don’t want to go through the trouble of tracking down all of this talent, you could always partner with an existing and trusted team of development experts. 

You can find such a team right here at Cheesecake Labs. Our developers and software engineers are highly experienced and educated. This simplifies the process of finding a team substantially and reduces the chance that you’ll run into errors and complications down the line. Reach out to discuss your options!

Step 3: Project execution and tracking

The third step of building a blockchain payment platform is execution. Here, you’ll work with your team to realize the vision you created during the project planning phase. 

Below are a few of the routes your project could end up going down during development. 

Route A: Creating a new blockchain and cryptocurrency

When building your blockchain payment platform, the first route you could take is to create a new blockchain and cryptocurrency. This requires:

• An IaaS solution (like AWS). This is what will host the original software, coins, and back-end tech for operating your blockchain payment system. 
• A Peer-to-Peer trading network. A P2P trading network will allow individuals to use your platform/cryptocurrency without the need for a centralized hub (like a bank). 
• A consensus algorithm. Consensus algorithms are critical to a successful blockchain. The consensus algorithm confirms that each new block is valid. 

Route B: Building a DAPP (Decentralized App) using Ethereum

DAPPs are a uniquely Ethereum payment platform model in the world of cryptocurrency. They allow individuals to purchase Ethereum, store it in a wallet, then connect that wallet to a DAPP. 

You can see examples of DAPP’s here on Ethereum’s official website. Some examples include investing Ethereum into art, swapping Ethereum tokens with ease, and mobile games based around Ethereum. 

Route C: Using existing Bitcoin or Ethereum payment gateways

Alternatively, you could build an app on top of an existing crypto payment gateway with an API. Coinbase, CoinGate, and Shopify all have APIs that you can use to facilitate the transfer of cryptocurrency. 

Building an app on top of these existing APIs is a fast way to get a creative idea out in the world. Just be aware that changes to these existing platforms and APIs could disrupt your service. So this route might be best treated as a starting point and not an ending point for your blockchain payment platform. 

Route D: Use Ripple, Stellar, or other existing blockchain payment systems

If you don’t want to tie yourself to the cryptocurrency world, you can instead use an existing blockchain payment system infrastructure that isn’t exclusively for crypto trading. 

Stellar, for example, uses blockchain technology to facilitate decentralized transactions in any currency. Your team could build an app on top of Stellar, adding unique features and selling points without being held to the cryptocurrency market. 

Partner with Cheesecake Labs and launch your blockchain payment systems in no time

Now that you understand what blockchain payment systems are and how to launch one yourself, it’s time to take that first step. Cheesecake Labs can help. Our team of development experts will work with you to bring your vision to life efficiently and effectively. 

Reach out today and explore your options.

The post How to create borderless, blockchain payment systems appeared first on Cheesecake Labs.

This guide will go through the ins and outs of blockchain, answering questions like how many blockchains are there, the benefits of blockchain, and how blockchain can be applied. 

What is blockchain?

Blockchain is a type of decentralized database that stores data in blocks chronologically. Each block is chained together using unique fingerprint-like identifiers called hashes. The database is hosted on a decentralized computer network that constantly runs checks to ensure the data agrees across all copies of the database.

There’s a lot in that definition to break down, so let’s take a look at each part with an example. For instance, say you were writing a paper. Every few minutes, you save that paper to avoid losing any data. A blockchain would allow you to see each version of that paper you created every time you saved it. 

These versions would be called “blocks” in the blockchain. Each block is a chronological variation of the initial version. The system verifies each block to ensure that the blocks match on every computer hosting the database. These verifications check to make sure blocks haven’t been tampered with or corrupted by an error. This is kind of like backing up your phone data to the cloud, only more secure.

That’s just one underlying aspect of a blockchain, though. Blockchains are also decentralized. So you could have multiple people working on the same document. Whenever someone saves that document, the system creates a new block in the blockchain with that version, and everyone plugged into the blockchain can see that new version. Additionally, everyone can see every past version (or past blocks) of that document. 

Of course, there’s no reason why everyone would have to be working on the same document to share a blockchain. For instance, a school could use a blockchain to keep track of every student’s essays for all time. Every time someone saves an assignment, the system creates a new block. So there are hundreds of versions of hundreds of documents, all stored in chronological order. 

This system could nearly eradicate plagiarism among students. If every version of every essay written by every student at a school is stored and secured chronologically, and every student and staff member can view this blockchain, then it would be impossible to copy another student’s work without being caught. It would also be impossible to lose the student work, keeping the record of that work safe.

What are the benefits of using blockchain?

True chronological record keeping

The primary benefit of using blockchain is, of course, also its primary function. Blockchain is an excellent way to store records chronologically. And since it’s so versatile, you can use it for virtually any kind of record-keeping. 

Software people who have worked with Git can likely see the similarities between Git and blockchain. Blockchain is so powerful because it applies the underlying principle of a version control system to nearly any kind of information — plagiarism protection, financial transactions, law-keeping, medical record storage, financial investments and so on. 

Blockchain is incredibly secure

Blockchain is also incredibly secure. It’s hard to overstate this. The fingerprint-like hashes that link each new block to the previous block in the chain create nearly unbreakable security. They can’t be separated or shifted around, which makes fraud and tampering almost impossible. 

Consensus reinforces blockchain’s security. Since a network of computers shares a blockchain and updates every record when adding each new block, it’s impossible to edit, add to, or otherwise alter the blockchain without others seeing those changes. 

Likewise, each change has to be “verified” by every other user of that blockchain. This means that each person’s copy of the blockchain must check and validate that blocks added by different users are legitimate. So nobody can falsely add new blocks.

It’s a decentralized way to store records

Lastly, blockchain was initially conceived to be decentralized. Like cryptocurrency (or even the internet), blockchain technology often exists outside of centralized moderation. When a blockchain is decentralized, it can’t be controlled or tampered with by governing bodies or corporate interests. 

Not only does this aid in building trust in blockchain record-keeping, but it also makes blockchain more accessible to everyone. Everyone using a blockchain also has their own copy of that blockchain, democratizing its use and keeping everything secure. 

How many blockchains are there?

In short, there are a lot of blockchains. People create new types of blockchains every day. It’s a flexible technology term, like SaaS, and you can apply it in just as many ways. 

There are four main types of blockchain, though. And most of today’s blockchains can be categorized under these types.

1. Public

The first and most common type of blockchain today is the public blockchain. These are blockchains that anyone can access and use. Most cryptocurrencies use public blockchains. 

Public blockchains are fully decentralized and immutable, so anyone in the world can access them without disrupting them. These blockchains are anonymous, too, so everyone can see the activity on the blockchain without knowing whose activity they’re viewing. This transparency makes blockchain perfect for cryptocurrency —  the transactions are publicly visible without giving away personal information.

2. Private

A private blockchain is one in which a single organization or individual has total control over the blockchain. You can think of this as a “proprietary” blockchain. A school, business, government agency, or even a person could control a private blockchain. 

Since a limited group of people uses this blockchain, it can run faster than a public blockchain. It also has the benefit of being more private and scalable. 

3. Hybrid

Hybrid blockchains are, as the name implies, combinations of public and private blockchains. They pull elements of each together in unique ways, keeping things confidential and proprietary without closing out the rest of the world.

For example, the real estate industry could use a hybrid blockchain to keep track of house sales. Only real estate businesses would have access to the blockchain, but it wouldn’t be limited to any specific real estate business, either. 

4. Consortium/Federated

Similar to a hybrid blockchain, federated or consortium blockchains combine elements of private and public blockchains. Federated blockchains keep certain features just for enterprise and share other elements with the public. 

For instance, a bank wouldn’t want to use a blockchain that is publicly available and usable. However, a bank would like customers to use a blockchain when making purchases and ATM transactions. So at certain times, the public can use the blockchain, while the bank exclusively manages the blockchain under different use cases. 

Notable and potential uses for blockchain technology

Throughout this guide, we’ve touched on a few use cases for blockchain technology. Real-world applications are nearly always the best way to understand how and why a piece of tech works. So let’s look at a mix of theoretical and real-world uses for blockchain. 

Bitcoin and cryptocurrency transactions

Kicking this list off is the use case that we’re all familiar with, Bitcoin and cryptocurrency transactions. 

Bitcoin relies on public blockchains, allowing everyone making Bitcoin transactions to ensure that the transaction is valid. There’s no need for government oversight, corporate or banking validation, etc. As long as two individuals have a medium for making transactions, they can and know that it’s valid. 

Verifying elections

An interesting application for blockchain is election verification. Though most elections still rely on traditional voting methods, blockchain voting is appearing more frequently, including in the 2020 presidential election in Utah County. 

In this use case, governments use a blockchain to keep track of each person’s vote. Blockchain voting has the potential to prevent issues like double-voting, lost ballots, voting by illegitimate individuals (e.g., deceased individuals), and so on. 

While voting systems could use private or hybrid blockchain systems, a federated blockchain would likely be the ideal solution. It would allow for the blockchain to be overseen and controlled by a governing body while also allowing individuals to interact with it when casting their votes. 

Managing medical records

An excellent possibility for private blockchain is in the healthcare sector. Specifically, hospitals could use a private or hybrid blockchain to keep track of every patient’s medical records. 

This would allow doctors to easily and quickly share medical data with hospitals all across your healthcare network. It would also provide doctors with an accurate and reliable medical history, allowing for more precise and prompt treatment. 

Filing taxes securely

On a federal level, individuals could use blockchain to file taxes. Along with being a substantial upgrade/overhaul to the tax system in many countries, this would also boost security and remove the widespread fraud that often affects large-scale tax systems. 

The transparency of blockchain would make it impossible to hide fraud from government agencies. And the security of the system would be a boon to citizens. 

Tracking cattle

One unique use for blockchain technology is as a means for tracking cattle. There has been an issue of tick-infected cattle undermining Zimbabwe’s beef exports in Zimbabwe, jeopardizing a valuable market for the country. External buyers want assurance that beef isn’t coming from infected cows. When they don’t get that guarantee, they’re buying beef elsewhere. 

To solve this, Zimbabwe has partnered with E-Livestock Global to track the medical history of cows using blockchain technology. Since this medical history is immutable, farmers can prove that a tick hasn’t infected a cow before a sale, reassuring buyers that the beef they’re purchasing is safe. 

Safe marriage certifications

Marriage Unblocked is another unique use case for blockchain. It uses public blockchain technology to allow couples to recite vows and marry one another, regardless of their orientation, gender, race, or other discriminated factors. 

Their marriage is validated and stored on the blockchain, where it will remain unchanged and unremoved, forever on the internet. For LGBTQ+ and inter-racial couples in discriminatory regions, this provides a safe alternative to state-owned marriage ceremonies. 

Reduce counterfeit wine

Like the farmers in Zimbabwe, wineries are using blockchain tech to verify the authenticity of batches of wine. This blockchain helps reduce counterfeit wine, which is a growing problem in the industry. 

How can you use blockchain in apps?

Of course, blockchain use isn’t limited to any of these sectors or cases. The only thing limiting how you use blockchain is your imagination, including in your apps. 

For app developers and businesses that want to invest in building an app, blockchain can increase your apps’ security, transparency, and stability in an unprecedented fashion. It can also help you craft experiences and solutions like no other. 

To learn more about how your brand can use blockchain and get help putting it all together, reach out to the team at Cheesecake Labs today.

The post What is blockchain? A guide for getting started with blockchain in your app appeared first on Cheesecake Labs.

Cheesecake Labs is currently the TOP #10 Mobile and Web App Development Company Worldwide and has delivered awesome digital products to our clients including Flutter apps.

When discussing architecture on Flutter apps, there are many ways to structure your code and widgets. The main goal of this proposal is to make your project easy to scale and keep everything organized at same time.

On this post, we’ll use the following packages:

• Dio: A powerful HTTP client for Dart
• GetIt: A simple service locator for Flutter and Dart
• Flutter BLoC: A package that helps implement the BLoC pattern

Creating a base structure

When you start a new project from scratch, you may have a project structure like this:

.
├── android
├── assets
├── build
├── ios
├── lib
├── test
├── README.md
├── analysis_options.yaml
├── pubspec.lock
├── pubspec.yaml

So let’s start setting up our directories in the lib folder as below:

.
├── components
├── constants
├── core
├── interfaces
├── middlewares
├── modules
├── utils
├── main.dart
└── routes.dart

Now our basic structure is set up! Don’t worry about all those folders and files, throughout the next topics we’ll cover the purpose of each one and why we need all of them.

Components: Atomic Widgets

Like React/React Native projects here at Cheesecake Labs, we work with Atomic System/Components to make our widgets more reusable and organized.

source: Brad Frost (2016)

In essence, we structure the components as:

• Atoms: The fundamental components like custom texts, buttons, icons and typography.
• Molecules: Basically, they are groups of atoms. One example is a list tile.
• Organisms: They are an association of molecules, like a custom list or a form.
• Templates: They are the final structure composed by organisms. Our pages/screens will use a template instance to set the real content.

Considering the information above, we can organize the components folder like:

.
├── atoms
├── molecules
├── organisms
└── templates

If you want to dive into Atomic System, we recommend the following articles:

• Rethinking Atomic React
• Atomic Design by Brad Frost

What are constants?

Constants are the code that is immutable in your application. The following can be considered a constant:

• Colors
• Styles
• Specific numbers

For example, if you need to change the color of the application or the size of the font that you are using, you’ll need to replace the old constant value in one file only.

The application core

The core layer is responsible for the services which the app will use all along its lifecycle. There are two core services we usually set up:

Dependency Injection

We can create a dart file and register our instances as the following:

GetIt getIt = GetIt.instance;

void startGetItModules() {
  _networkModules();
  ...
}

void _networkModules() {
  getIt.registerSingleton<Dio>(
    HttpHelper(dotenv.env['BASE_URL']!).addInterceptor(AuthInterceptor()).dio,
  );
}
...

It will allow us to provide dependencies to our classes, keep the instances easy to change for different implementations, and help separate the module layers.

Navigation

To help us work with navigation more efficiently, let’s create a custom navigator:

class RouteNavigator {
  static final GlobalKey<NavigatorState> navigatorKey = 
       GlobalKey<NavigatorState>();

  static Future<dynamic>? pushReplacementNamed<Arguments>(
  {required String routeName, Arguments? arguments}) {
    return navigatorKey.currentState
        ?.pushReplacementNamed(routeName, arguments: arguments);
  }

  static void pop() {
    navigatorKey.currentState?.pop();
  }
  ...
}

And to start using this navigator, you need to pass the navigatorKey to your
MaterialApp.

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'My App',
      navigatorKey: RouteNavigator.navigatorKey,
      onGenerateRoute: (routeSettings) {
         return MaterialPageRoute(builder: routes[routeSettings.name]!);
      },
      ...
    );
  }
}

By using this class, we’ll be able to navigate through the app with no context required, just by calling:

RouteNavigator.pushNamed(...).

Interfaces

When we develop an app, we usually need to communicate with an API or some external resource, such as a local database and sensors. So, the interfaces folder is the place where you store the files that will help you with this communication.

A common example is the creation of a Dio instance to work with HTTP Requests:

class HttpHelper {
  final String _url;
  late final BaseOptions _options;
  late final Dio _dio;
  Dio get dio => _dio;

  HttpHelper(this._url) {
    _buildBaseOptions();
    _buildHttp();
  }

  void _buildBaseOptions() {
    _options = BaseOptions(
      baseUrl: _url,
      responseType: ResponseType.json,
    );
  }

  void _buildHttp() {
    _dio = Dio(_options);
  }

  HttpHelper addInterceptor(Interceptor interceptor) {
    _dio.interceptors.add(interceptor);

    return this;
  }
}

Middlewares

Middlewares are responsible for providing an extension to an event or action from your application. This can be an HTTP request interceptor, a logger or something similar.

Here you can see an example of a middleware that throws a custom error when the request to an API returns the status code 401:

class AuthInterceptor extends Interceptor {
  @override
  void onError(DioError err, ErrorInterceptorHandler handler) {
    if (err.response != null) {
      if (err.response?.statusCode == 401) {
        throw UnauthorizedException();
      }
    }
    handler.next(err);
  }
}

Modules: A hexagonal architecture approach

This folder is the most important, as it contains all modules that implement our features and its business rules. Here we’ll use an hexagonal architecture approach in a way that allows us to separate our application layer from the domain layer and the infrastructure layer. So, every module will be structured according to the following architecture:

With this architecture, the code will be more organized, but we also need to modularize it to make it easy to add a new feature, modify the old ones and make the code more reusable.

So, we suggest you structure the modules as:

.
└── feature
  ├── blocs
  │
  ├── data
  │ └── datasource //abstract datasources
  │ └── repositories //implementation of abstract repositories
  │
  ├── datasource //implementation of abstract datasources
  │
  ├── domain
  │ └── entities
  │ └── repositories //abstract repositories
  │
  └── screens

Separating the modules this way allows us to use different implementations for every layer. We can, for example, create multiple different screens with the same domain logic or even change all the data source providers without affecting the entire application. For example, our app is separated into independent pieces which are able to work individually.

Moreover, this approach supports testability, which is a good point for building a reliable project and improving code quality.

Conclusion

When you are dealing with complex projects that contain many features, this architecture is a lot of help when it comes to keeping everything organized, easy to modify, and extremely simple to maintain and to test the code along the development process.

This is just an efficient way we’ve come up with to structure our Flutter projects here at Cheesecake Labs and we hope it helps you as well.

Would you like to know more about how to use Flutter to get your project off the drawing board? Contact us!!

References

• https://martinfowler.com/bliki/PresentationDomainDataLayering.html
• https://resocoder.com/2020/03/09/flutter-firebase-ddd-course-1-domain-driven-design-principles/
• https://bloclibrary.dev/#/architecture
• https://medium.com/flutterdevs/explore-clean-architecture-in-flutter-3fff83e0f1f2

The post How to architect delightful Flutter projects appeared first on Cheesecake Labs.

After all, Flutter is backed by Google and used by some of the biggest apps in the world. In this blog post, we’ll explore what’s so powerful about Flutter as a cross-platform framework and which apps you can draw inspiration from for your upcoming development project.

What is Flutter?

Flutter is a cross-platform mobile app development framework. It includes a set of tools to help developers make high-quality apps for iOS and Android with great ease and speed.

Flutter was released by Google in 2018. It’s still one of the newer cross-platform development tools, but it has quickly gained traction — and is now what powers many of your favorite apps.

Its speed, simplicity of use, and flexibility make it a popular choice for developers and app owners alike.

What makes Flutter a great choice for mobile app development?

Google created Flutter with a single-minded goal: to provide a toolset for developers to build cross-platform mobile applications easily. In its short time since launch, Flutter has continued to grow and has released even more features to improve and streamline the app development process.

While other cross-platform frameworks like React Native can also provide this functionality, there are a few things that set Flutter apart from its competition.

You may also like:
Getting you up to speed on Flutter vs React Native vs native development

Flutter compiles to native code (rather than interpreting)

Cross-platform frameworks empower developers to quickly and efficiently create mobile apps. And while that’s a huge benefit of cross-platform development on the whole, Flutter and its fellow cross-platform framework — React Native — does so in different ways.

Many cross-platform frameworks, like React Native, use an interpreter to run applications. An interpreter is like a medium between your application code and a smartphone. It translates your application’s instructions in real-time to a smartphone, so it functions correctly for your users.

As you can imagine, this is an additional step — and comes at the cost of development speed, however negligible but impactful on time to market.

Flutter, on the other hand, compiles its code directly to a smartphone’s native code. It skips the interpretation step, and as a result, you get a faster application. While you can get similar performance with other cross-platform tools, you have to do some extra work to get there.

Flutter keeps your options open in terms of cross-platform UI (user interface)

You know how important a seamless, consistent digital experience is — no matter what device your user has in their hand. With Flutter, you’ve got options for how you make this happen. You can roll out the same user interface across Android and iOS, or you can create different designs from one platform to the next.

Having the same user interface on every device means you know for sure your brand is consistent everywhere. It doesn’t matter how old a device is or what operating system your users are working with — your UI and experience will always appear the same.

That said, sometimes it makes more sense to have custom experiences for Android users and iOS. And in those instances, Flutter is still a great choice for your development framework.

Flutter has plugin infrastructure

The Flutter framework supports a large plugin ecosystem, providing developers access to add native functionality by importing code to their projects. These features can be anything from Bluetooth access to GPS locations — improving your app’s experience and delivering more value to your users (and business).

Many of these plugins are created and maintained by Google too, so you know you’re getting great quality software for your app.

Flutter goes beyond mobile

For many cross-platform development frameworks, mobile is the stopping point. If you want to build on desktop computers or another platform, you’ll need another codebase. But that’s not the case with Flutter.

Google’s newest version of Flutter gives developers the ability to use their Flutter code on other devices, including web. You can now use one codebase for mobile, Windows, macOS, and Linux devices — further adding to Flutter’s cost-effectiveness and flexibility.

6 of our favorite apps built using Flutter

More than 100,000 apps use Flutter, reaching millions of mobile devices. The question is, how many big-name companies use Flutter to make their software run? And what can we learn from them?

Below are just a few of our favorite examples of Flutter in the wild…

1. eBay Motors

The first app we’ll take a look at is eBay Motors.

eBay needed a way to provide a great shopping experience for its users looking to buy cars online. Sure, a web browser may have been the first choice a few years ago, but now — with the rise of mobile — that’s not what users are after. Instead, the app needed to utilize a smartphone’s in-built features; managing listings, uploading media, and finding vehicles to purchase on the fly.

Flutter allowed eBay Motors to provide a seamless vehicle shopping experience online. eBay Motors put the pedal to the metal with Flutter 1.0 — delivering the first beta version of their app within just three months.

Download eBay Motors for Android here, and iOS here.

2. Nubank

Nubank has been a mobile-first company since day one. At their start in 2013, they relied on Kotlin and Swift to create their mobile experiences. But as the company grew, it needed to expand its capabilities.

Nubank turned to Flutter to meet the growing demands of its app. Flutter allowed Nubank to expand on its app’s capabilities without writing the whole app from scratch. As time goes on, most of the codebase will migrate to Flutter as the rest of the codebase phases out.

Download Nubank for Android here, and iOS here.

3. Grab

Grab is a platform that allows local restaurants to deliver food straight to their customer’s doors. Users head to the app to order their food online and wait for a delivery driver to deliver their meal. But we don’t need to explain the online food delivery model to you — with a year on year growth of 20.2%, there’s no doubt you’ve experienced it for yourself.

To help merchants take advantage of this growing market, Grab needed to create a mobile app that gave restaurant owners control over their delivery business.

Powered by Flutter, merchants can track orders, view reports, add team members, and everything else needed to manage their deliveries with ease.

Download Grab for Android here, and iOS here.

4. Topline – Abbey Road Studios

Topline is an app developed by Abbey Road Studios to help musicians save song ideas while they’re on the go — whenever inspiration strikes! Just a few taps on the app and lyrics, audio, and other files are saved instantly on the cloud. Once there, these thoughts and visions can be shared and synced across their team.

Abbey Road Studios took advantage of Flutter to build their app in just 10 weeks. It was featured in Google I/O 2018 and won two awards in the UK App Awards 2018.

Download Topline for Android here, and iOS here.

5. Hamilton

Broadway theatre and emerging tech doesn’t always go hand in hand. But the app for stage-sensation, Hamilton, is an exception to the rule. The stage show’s official app connects theatre-lovers to exclusive content, merchandise, and even daily giveaways.

Speaking about how Flutter improved the process, Hamilton’s digital design partner said: “Flutter made it possible to deliver more and at a higher level of quality. If we had developed two independent fully native apps, we never would have shipped the feature set we had at launch.”

Download the Hamilton app for Android here, and iOS here.

6. MGM Resorts

MGM is one of the biggest names in US hospitality, with venues and experiences in Las Vegas, Detroit, Massachusetts, and elsewhere across the States.

In a sector where speed and seamlessness are key ways to outshine the competition, MGM’s Flutter-built Android and iOS apps support digital room access, personalized entertainment recommendations, and real-time dinner reservations.

Download the MGM app for Android here, and iOS here.

Start your next Flutter application today — and count on Cheesecake Labs to deliver results

In a world where being nimble and adaptable is essential to stay competitive, you can’t afford to work with older, slower development methods. Flutter won’t only help you launch your next app in less time, but it will also help you maintain your app in the future.

Are you thinking about using Flutter to build your new app? Reach out to the Cheesecake Labs team and talk to the group of experts who can make it happen.

The post Apps built with Flutter — 6 great examples appeared first on Cheesecake Labs.

The good news is we now have plenty of options to choose from. And, at CKL, we’re fully trained and ready to go using a range of different programming languages and frameworks — whichever is the best approach for your project. All that remains to resolve is which is better for your app when it comes to Flutter versus React Native versus native development.

Flutter versus React Native versus native apps — what’s the difference?

You have two main options when developing mobile apps: cross-platform and native development. 

In native development, you take advantage of the tools provided by the device’s operating system:

• For Android devices, you use Kotlin programming language with the Android SDK.
• For iOS devices, you use Swift alongside the iOS SDK.

Things are a little different with Flutter and React Native. Instead of using the native tools provided by the device’s operating system, you use cross-platform tools to create one codebase for your whole app.

In simple terms…

• React Native is a framework for building native iOS and Android applications using JavaScript. It’s based on the same concepts as React, but uses native components to render a user interface (UI).
• Flutter, on the other hand, uses the Dart programming language to compile the native application, re-implementing native components with identical UI and experience.

While React Native and Flutter can be used to create the same result — a delightful digital experience — there are quite a few differences in how they work. So let’s unpack each in a bit more detail.

You may also like:
Here’s how the world’s most innovative brands use React Native (+5 great examples)

Apps built with Flutter — 6 great examples

React Native versus Flutter: a visual overview

React Native:

• A cross-platform framework using native components to render a user interface (UI)
• Released on March 2015
• Created by Facebook
• JavaScript (a very popular programming language)

Flutter:

• A cross-platform framework that compiles to native code, using identical replicas of native components on the UI
• Released on December 2018
• Created by Google
• Dart (a type safe programming language, benefiting from fewer runtime errors)

What is React Native?

React Native is a development framework created by Facebook in 2015. It was conceived as an extension to Facebook’s original React framework, extending its capability to mobile.

React Native developers rely on the JavaScript language to build their apps. It provides a set of building blocks that let developers quickly and easily build mobile apps. These building blocks wrap a mobile device’s native code, meaning developers can easily create cross-platform apps that match a phone’s native user interface.

Pros of React Native

Tons of talent

React Native uses JavaScript — the most popular programming language for the eighth year in a row! That means you’ll have your pick of great developers to help build your React Native app (particularly versus Flutter, which uses Dart — a language that isn’t half as popular in 2021). And while you can find great people with other frameworks, it’s hard to find the same abundance of talent as you would with a popular programming language like JavaScript.

A vast and growing community

React is also one of the most popular JavaScript frameworks out there. There’s a large community and plenty of training for React Native developers to take advantage of.

Better still, React is also the most “wanted” framework according to the Stack Overflow Developer Survey 2020, meaning we should see even greater adoption and talent development in the future.

Cons of React Native

Fewer native components

React Native provides a lot of power to its developers. It lets them create custom UI components and apply them across their application. However, this also means you need to make all those components from scratch.

React Native comes with fewer off-the-shelf components versus Flutter and its alternatives. If you want to get up and running quickly, working with a framework that contains more components might be a better option. Or you could use React Native + a UI framework like Material UI or RNUI. The final result won’t be super customized, but it’ll help you achieve a sweet spot between bespoke builds and speedy time-to-market.

More likely to break with new OS versions

Your React Native app uses the phone’s native styling when rendering your UI. On one hand, this means your app will look great on devices where you know how the styling works. But on the other, every now and then you’ll be met with problems as operating systems update and change their styling.

You’ll need to test your app’s user interface every time a new OS version is released. Google and Apple also change how their phone’s UI works at times, so you’ll need to adapt quickly to those changes too.

Abandoned packages

Versus Flutter, the React Native ecosystem is enormous and provides a lot of pre-built packages for developers. While this lets them produce apps more quickly, it becomes a problem when a package developer stops updating their software.

React Native has many abandoned packages in the wild. Your developers will need to make sure they’re using software that’s likely to stay updated in the future (if there is such a thing!) and make sure everything they currently use still gets updates.

What is Flutter?

Flutter is newer to the cross-platform development scene versus React Native. Google released the framework in 2018 and it’s grown a lot in recent years.

Google’s Flutter makes use of the Dart programming language to build mobile apps. Unlike React Native and other popular cross-platform tools, Flutter compiles down to the same native app code that native apps use to run.

So what do you stand to gain — and what can hold you back — when choosing Flutter versus React Native?

Pros of Flutter

Apps with better performance

Speed is a common concern with frameworks based on JavaScript. These applications need to jump through hoops to run code native to mobile devices. Lower performance isn’t an issue in most cases, but can cause problems if you have a performance-intensive app idea. 

Flutter frees you from such limitations.

Since Flutter compiles to native code, there’s less friction when running these applications. This means Flutter apps that are built right see better performance than other development frameworks, assuming your app will have a single view for both Android and iOS devices.

The same UI on all platforms

It’s tough to manage varying UIs on different platforms. You need to always be on your guard against new updates to make sure nothing in your UI breaks. But since the Flutter UI appears the same on every device, this simply isn’t an issue.

The Flutter UI you build will work the same on every mobile OS and every version of those systems. This conformity means less testing and fewer bugs for your developers to deal with.

Out of the box components

If speed is vital for launching your app, Flutter is a great cross-platform choice. It provides more out-of-the-box native components than other competing frameworks.

These components will help your developers prototype and get to an MVP. You won’t need to wait on your team to create the custom React Native components you need.

Cons of Flutter

Fewer developers (as it stands today)

Having the features of Flutter isn’t worth much if you can’t find people to build your app or help maintain it. Flutter’s developer community is modest but growing, so as it stands today you may encounter a talent shortage when developing your app with Flutter versus React Native and other frameworks (although not at Cheesecake Labs).

Before starting a Flutter app, you’ll need to ensure you have the people available to deliver your vision. You could also face challenges onboarding new talent since there aren’t as many resources available to learn the programming language.

You simply need to pick your partners wisely.

Fewer third-party libraries

An abundance of third-party libraries awaits when working with popular programming languages, like JavaScript. These libraries help you get apps up and running quicker than creating everything from scratch. 

Flutter and the Dart programming language aren’t quite there yet.

The Flutter community is still small, so there aren’t as many resources available to build more complex app functionality. If your app needs more done than native components can provide, this can increase your development time.

Cross-platform vs. Native: what should you choose for your app?

Now that you know what React Native and Flutter can do, the question is: should you pick one of these cross-platform development frameworks over native applications?

A native app requires you to use the programming language native to your phone. For Android phones, that programming language is Kotlin. For iOS devices, you’ll use Swift. If you want an app that runs on every phone type, you’ll need to write your code from scratch for each one — and maintain each codebase separately.

Things work differently with cross-platform apps. A cross-platform development framework lets you use one codebase for both Android and Apple devices. And therein lies the benefit, if you ask us.

Working with one, cross-platform codebase…

Reduces time to market

Speed is a crucial component in the development of some apps. If you’re in a competitive market, launching your app quickly is vital to stay one step ahead of your rivals. If you need to create two codebases for your app, it’s harder to make this a reality.

A single codebase lets you launch your app on every device at the same time. Cross app frameworks are optimized for both devices, so you’ll spend less time coding and fighting device-specific software bugs, too.

Is easier to maintain

As we discussed in our post about the Product Optimization phase, the app development process of a successful product never ends. There’s always updates to adapt to, bugs to squash, and evolving user demands your app needs to meet.

A single codebase is easier to maintain since the Android and iOS versions will share much of the same code. You can make changes quickly and launch updates on every phone at the same time.

Four examples that show you what’s possible with cross-platform development

These four apps — one that we built, and three that we love — are a great indication of what cross-platform development can do.

Power Play Rewards by exMox

Cheesecake Labs created the exMox app to provide a performance marketing network dedicated to gaming. React Native was chosen to offer a seamless experience across Android and iOS devices.

The exMox software provides game publishers with a way to keep players engaged. It gives personalized incentives and rewards, the latter of which can be used on in-app purchases, and dencourages players to invite their friends.

Instagram

What better example of a cross-platform app than one of the largest one in the world? Instagram makes use of React Native to provide a great experience for users on any device.

Instagram’s developers use React Native to push updates to all devices at the same time. It simplified their codebase, allowing them to expand Instagram’s features and protect their stake in the competitive landscape.

Grab

The Grab app was created for Android and iOS devices to give food delivery businesses an easy-to-use mobile app to manage their business. Grab used Flutter to provide a consistent experience across every device the app runs on.

This app allows merchants to view the data about their store in one place. They can see sales, view refunds, manage employees, and manage menus.

BMW

BMW took advantage of Flutter to build their mobile app for car management. The app connects to BMW vehicles through bluetooth to give their drivers a dashboard to manage their vehicles.

A driver can check on their vehicle’s health, locate their vehicle, find fueling stations, and much more. Flutter allowed BMW to do all this from one codebase instead of creating a separate version for Android and iOS devices.

Cross-platform development sounds great…. So why does anyone go native?

Cross-platform development offers a lot of benefits compared to native development. However, that doesn’t mean native development isn’t worth pursuing if it leads to a better app for you.

Some developers are wary of relying on big companies to maintain their frameworks. React Native is maintained by Facebook, while Google keeps up Flutter. If either of those companies decides it doesn’t make business sense to support those frameworks anymore, anyone using them is out of luck.

But let’s be honest: Facebook and Google are two of the biggest tech companies out there, so the chance of that happening is minimal. Even if it does, these projects are free and open-source — there will always be a way for the community to continue its development, the same way it happens with other popular programming languages and frameworks. 

And beyond the cons of cross-platform frameworks covered above, native apps have a few other benefits to consider…

The benefits of native development

Native apps are fast

React Native and Flutter both do a great job at giving users a great experience, but neither can measure up to the speed of native apps. While you can make high-performing apps with React Native and Flutter, native apps make it easier.

While Flutter is faster than React Native in this regard, it still doesn’t match native speeds. If your app needs as much performance as you can give it — for a high-demand CPU or a low-latency app like 2D/3D gaming experiences — then native is likely the best choice.

Easy access to native phone functions

Mobile phones come with a lot of cool features these days — with everything from facial recognition to GPS built right in. In the past, it hasn’t always been easy for cross-platform apps to access these functions.

And while things have improved, cross-platform still has some way to go. You need to add several layers of components to Flutter and React Native if you want your app to use a device’s advanced in-built features, like AR and Machine Learning. With native development, you have easy access to everything a phone can do.

Trust Cheesecake Labs to deliver the solution you need

While you can use any of the tools above to deliver you the app you’re looking for, one of them might be a better choice for your specific needs. 

It’s also important not to let the hype get in the way of intelligent decision-making. Sometimes a new technology like Flutter can seem like the next best thing, but it isn’t always the right choice for your business.

Our 7+ years in mobile development have taught us this fact. That’s why the Cheesecake Labs team will look at the pros and cons of each development methodology, present the information back to you, and help you choose the one that’ll do the job best. Our team knows Flutter, React Native, and native development — so there’s never any compromise on quality.

If you’re ready to sit down with a mobile expert and learn more about your options, then you know where to find us.

The post Getting you up to speed on Flutter versus React Native versus native development appeared first on Cheesecake Labs.

But what exactly are we referring to, when we say “quality”?

Understanding true quality in application development

At a minimum, a quality app is one that allows its users to accomplish their goals without anything going wrong. Their experience should be bug-free and have no unexpected behavior. Without great QA, you run the risk of releasing buggy applications and wrecking your company’s reputation.

Accomplishing this isn’t only important for users, either. It’s critical for app owners too. An app that has minimal bugs costs less to maintain and fix — you’ll spend less money in maintenance mode and more time in development adding new features that help meet your business goals.

That’s the hidden benefit of masterful QA. And it’s why, at Cheesecake Labs, we view quality as way more than technical viability and functionality.

Let us tell you more…

Quality assurance baked in at Cheesecake Labs

At Cheesecake Labs, quality assurance isn’t only about finding bugs and fixing them — although we’ll obviously do that too!

Large applications are complex, and a lot can go wrong. Not everything bad will appear as a bug. Our QA team’s job is to find and resolve these issues, delivering a product that meets the needs of the client and the end user.

Spotting and resolving bugs is just one responsibility of the Cheesecake Labs QA team though. In our house, QA has the same level of input to the total development process as designers and developers. They participate in each of a project’s weekly meetings, are active in Slack chats and have a direct communication line with our customers. They’re there to make a meaningful difference in every part of the app development journey.

Your QA team is also there to make sure your app meets all the business requirements. At Cheesecake Labs, QA operates as part of the ‘Project’ team — that is, they are active during every one of your product’s design and development cycles, end-to-end.

Where the QA process kicks off

Quality assurance isn’t an afterthought at Cheesecake Labs. Our QA team joins the project at the start of the Design phase where, at this point, they’ll learn about your company and the goals of your application.

Knowing this helps our QA team understand who your customers are, how they want to use your app, and how to deliver feedback that leads to great results. It isn’t always easy to prioritize features efficiently from the get-go. But since our QA team knows your app’s goal and what your users need, they can test your app to make sure the user interface functions well for everyone and provides that delightful experience.

Moving to development

Once we move out of the Design phase, the QA team starts their work with the development team. As the development team releases your app’s early builds, the QA team will be there to test everything. They’ll perform functional and usability tests to make sure everything works as intended.

They’ll use their findings to provide constant feedback to developers. This iterative approach helps your engineers deliver quality code and gets your app in-hand more quickly. QA will keep this focus on continuous improvement through both Development and Optimization.

The quality assurance tests your product needs

If you ask us, there isn’t one type of QA test that covers all the bases. If you want a quality application, you’ll need several testing methods to get you there. That’s why we’ll apply a series of different approaches and test suite cases to your project, depending on its needs.

The QA tests we rely on vary from unit tests to end-to-end tests, and more in-between. But let’s look at three quality assurance tests that Cheesecake Labs uses regularly and why they add value.

Smoke test

A smoke test is rolled out when you’re almost ready to release your app for further manual tests. You can think of it as a verification test to make sure everything is operating correctly.

Smoke tests contain a small set of manual tests that you run on each software build. These tests cover the most critical parts of your application — and if there are any significant issues with your software, these tests will find them.

Regression test

Just because a feature is working now, doesn’t mean it will continue working in the future. As time goes on — and more features are added — there’s always the chance that previous functionality breaks when you introduce new code.

That’s where regression testing comes in; looking at previous features of your project when new builds are released. Your testers and developers will have created a set of test cases for those features, and those tests are rerun to make sure nothing breaks and old bugs aren’t reintroduced.

Integration test

Your app features don’t exist independently. Many parts of your app will need to communicate between the other parts, and integration testing helps isolate any issues.

An integration test looks at your whole application, from top to bottom. It tests both your frontend and backend code to ensure your entire app flows seamlessly.

How does Cheesecake Labs make these tests happen?

These tests can happen in two ways: manual or automated. Manual tests are more often applied to the user interfaces for your software. These tests make sure your users see what you want them to see, so it’s tough to automate that process.

Manually testing every part of a large application isn’t always feasible, though. So that’s where automated tests, like unit tests and UI tests, are added in.

Unit tests are applied to test small pieces of code in your product’s backend; whether it’s a function, module, procedure, or object, running an automated unit test will ensure everything’s working as expected.

UI tests, on the other hand, are used to mimic user behavior. An automated UI test works through your app completing tasks as a genuine end user would — navigating workflows, validating buttons, inputting data, and so on. Performed automatically, this helps us test long customer journeys — and isolate issues — more quickly.

Keeping you in the loop through QA

The entire Cheesecake Labs four-phase product development process is founded on collaboration. And while QA can be technical, we’ll never work in a silo or isolation.

Our QA team will keep you updated every week. You’ll know how many bugs we discovered and fixed, why those bugs occurred, and unexpected program behavior. Plus, when you work with our QA team from the very beginning, you’ll get a program with fewer bugs and an app with all its major features working correctly — and that saves time for everybody!

What happens if you create parts of your app in-house?

Are you using Cheesecake Labs to create your app’s frontend while you handle the backend code yourself? No problem!

Our team is more than happy to work with your in-house developers and have done this with many clients. We understand that issues can come up when working with two separate codebases — and that, in most cases, those issues will show up on the frontend of your app.

Should this occur, our QA team will work with your team to find any issues and resolve them. Your success is our success, so we’ll do everything we can to get to the root.

Let’s prioritize quality, together

Building an app is a team sport. By bringing QA into the process at the Design phase, your testers, designers, and developers can stay on the same page. This is even more important in today’s world where much of the workforce has gone remote.

Your Cheesecake Labs QA team is also there to help create guidelines and documentation. Everyone will know what to do, they’ll be aligned on your product vision, and can work seamlessly together to achieve your business goals.

Schedule a consultation today to get the process started.

The post Quality assurance — the CKL way appeared first on Cheesecake Labs.

At Cheesecake Labs, we cut through the noise.

We’re clear about why we use Python — the benefits it brings to application development and the drawbacks too. We know what the benefits of Python are, the advantages and disadvantages, and why, in our opinion, Python is so great.

If you want to learn more about Python, the good and the not-so-good, keep reading below.

What are 3 benefits of Python?

There aren’t enough words to describe all the benefits the Python programming language brings. And that very fact helps illustrate why Python is so popular with engineers.

That said, there are a few advantages to using Pytho that stand out from the rest:

Benefits of Python: Simplicity and readability

If you asked several Python programmers to create an application to handle a specific task, you would think that you would see vastly different coding styles and structures. In some languages, this is common. Python, on the other hand, keeps developers on the same page.

Python adopts the view that programming code should be readable and straightforward. There aren’t too many ways to accomplish tasks, and Python wants its developers to handle things in a certain way.

While some programmers might find this constraining, it makes life easier for others — including their clients.

Having simple and consistent programming code means that any engineer can look through Python code and understand what’s happening. This lets companies onboard new talent and get them up and running more quickly.

“As a client, this means your developers are more focused on delivering the business objectives than they are on determining which way of doing things is the best. Developers can focus on solving core business problems and launching apps efficiently.”

– Douglas Gimli, VP of Business Development

Benefits of Python: Large community and ecosystem

Python is an open-source project. This means that the source code for the programming language is open to everyone to read and propose changes. It’s built by developers, for developers.

As a result, Python is now one of the most popular programming languages on the market. Many educational institutions list it as the number one language for new developers to learn.

The extensive developer base has also led to many tools that make a developer’s life easier. These tools can integrate with business applications and let programmers do more with less code. You’ll get your applications developed faster and with fewer bugs too.

The Python community is also very friendly. Developers across the world regularly share answers to complex problems, and a Python programmer working on your app can quickly find solutions to issues they face. The outcome? Greater project velocity and a smoother route to market.

Benefits of Python: Versatile developer tools

One of the most significant advantages of using Python is the abundance of developer tools and third-party libraries. One of the biggest time-sinks in development is creating everything from scratch, but with Python, you save time not having to build things that’ve already been built before.

How does Python achieve this?

For one, it has a lot of built-in features that make developers’ lives easier. The standard library contains program functions that let developers accomplish tasks in a few lines of code, something that would otherwise take a lot more.

If you need something more complicated than the Python library provides, you only have to look to the open-source ecosystem. There you’ll find tools for everything from machine learning to web development, and all a Python developer needs to do is install the library and get started on their task straight away.

People use these tools in a large number of industries. Data scientists make heavy use of machine learning tools to get data models up and running, and web development companies use frameworks like Django to build websites quickly.

“Again, all of this leads to a much faster build. With the best tools close at hand, we can leverage and optimize development time. Delivering solid-rock code and, ultimately, total value to your business — all in less time, and with a tighter budget, too.”

– Jeremy Stephan, Head of Client Engagement

Are there any downsides to Python?

There’s no such thing as a perfect programming language, and the features that Python provides do come at a cost.

Let’s take a look at some of the downsides you’ll see when using Python as a programming language:

Lower performance?

Search online for Python comparisons or how-tos, and you’ll find multiple articles stating that Python is slow. But what does it mean, exactly, in the context of other programming languages? And how much of a deal-breaker is this “slow/low performance” when adopting Python for your application?

Without getting too deep into the technical details, “Python code” is in fact slower than code written in low-level languages, such as C/C++. Why? Because Python is what’s known as a dynamically typed and interpreted language — and there are extra steps that Python code needs to take, to turn into code that computers understand.

Low-level languages compile into machine code, so there’s less work to do when your software is running.

Note the use of “Python code” in inverted commas above, though. We did that for a reason.

When you’re building an app that demands high computation — for machine learning, let’s say — many of the Python tools you’ll use mostly run as C-compiled code, with a Python wrapper. This means you can get a good balance of Python’s ease of use, plus speed from C, with a small overhead.

For applications like web development, Python code is hardly the most common performance bottleneck. Real-world applications are complex in nature, and they have to integrate with several third-party services that have a higher chance of impacting the overall performance — database, email, messaging queues, and so on. And unless you address the main bottleneck of the application as a whole, you won’t be effective.

Where the bottleneck can be identified as the Python code itself, you can always integrate with other languages like Golang. Problem solved.

So with no issue being too big to resolve… is it actually worth undergoing all these performance workarounds just to use Python?

The answer, for us, is a resounding yes.

Successful digital products are those that ship value to their users consistently. In order to achieve that, you have to be able to prototype and implement code that represents the world closest to its real form, without getting swamped with low-level intricacies.

In a world where hardware gets less expensive year after year, being able to develop applications and adapt faster is the real game-changer, and Python delivers on this promise.

Issues with interpretation

The ease of use and development speed that Python brings as an interpreted language (and not a compiled one), has its benefits and its trade-offs.

In the exact same way you might use an interpreter to understand what someone else is saying in a different language to your own, Python code itself undergoes an interpretation process — each line of code is read, analyzed, and executed during application run time. And you may find an interpreted language like Python creates more runtime errors, when compared to statically compiled ones.

These errors can be prevented, though. A modern software development toolset with static code check, linters and automated tests bring peace of mind to Python engineers, leaving them to focus on solving real-world problems.

Of course, the Cheesecake Labs expert QA team is also on-hand to weed out any potential runtime errors before you hit the market.

Python + Cheesecake Labs = delightful digital experiences

Now that you know more about what makes Python great, the question is: how does Cheesecake Labs use Python to produce outstanding applications?

Essentially, the Python ecosystem lines up well perfectly with the Cheesecake Labs development process and our engineering culture foundations:

Quality

Python is a robust language that makes sure its developers handle things the right way. This encourages dev teams to create quality code that other developers can understand. It makes applications more stable, easier to debug, and easy to enhance in the future.

All this leads to better experiences and results for you (our customer) and the end user (your customer) too.

Efficiency

There’s a fine line between delivering quickly and delivering quality. You don’t want to speed through the creation of an app, only to end up with a disappointing outcome. That’s never an issue with Python and Cheesecake Labs though — together we stay efficient and still deliver excellent results, focusing on the right value for your users.

“The Python ecosystem provides us with the tools we need to get things done and get them done well.”

– Bernardo Smaniotto, Chief Operating Officer

Transparency

Python makes it easy for Cheesecakes Labs to work quickly and collaboratively with clients. Once your digital product is out there in users’ hands, we’ll be assessing and exploring ways of making your app even better (that’s all part and parcel of our fourth phase of product development, Product Optimization) — and Python facilitates the speed of that process.

Using Python, we’re able to easily translate the real-word use case to code and deliver that benefit to your users with no wasted time.

Python also makes it easy for us to figure out any issues that come up with your software; the Python developer tools help us find bugs and squash them. It helps us keep you updated on our progress and what’s going on with your application too.

So before we wrap things up — and in the name of transparency as well — it needs to be said: Python won’t be right for every project. You need to find the right tool for your job, so the development team you collaborate with needs to be well-versed in all the tools available.

You can trust the Cheesecake Labs team to not only give their honest, expert opinion on which programming language is right for you, but we’ll also have all the resources and skill-sets required to make a success of your app: Python, Node.js, Golang, or otherwise.

3 apps built by Cheesecake Labs on top of Python

With all the benefits of Python, it’s no wonder Cheesecake Labs has used it for 7+ years.

In all that time, we’ve created some great applications for our clients. Let’s check out a few of them and talk about how Python helped make them a reality.

AES VPP

The AES virtual power plant software was one of Cheesecake Labs’ first ventures into the energy market. Virtual power plant software is responsible for connecting renewable energy sources into the grid for businesses, generators, and storage systems.

Cheesecake Labs used Python for the backend, and optimization algorithms. It helped create evolving algorithms that connect with third-party sources to create a robust environment. That data is used for data visualization that helped AES create graphs, forecast pricing, and gauge asset availability.

Skyroam

Skyroam is a global WiFi hotspot manufacturer. They saw limitations with their Shopify website and wanted to create a robust shopping experience for their customers. That’s where Django held the solution.

Cheesecake Labs used the Django Framework to create a custom-built eCommerce system for Skyroam. We migrated Skyroam off Shopify to a highly-scalable AWS cloud webserver that can meet Skyroam’s global expanding needs.

Boma Global

Boma Global is a leader in corporate education. They provide networking opportunities for organizations and individuals that are driving some of the most innovative companies across the world.

Cheesecake Labs helped Boma Global by updating its website experience. We used Django to create a custom-built website to inform Boma Global’s customers about their business — connecting users with event information, and helping them sign up for updates and events, while discovering more about the Boma Global network.

What could Python (and CKL) do for you?

By now, you should know the benefits of Python and why it’s an excellent choice for your next application. Now all that’s left to do is put that insight into action.

If you want to learn more about using Python for your project, get in touch. Our team will gladly walk you through the development process and start bringing your business idea to life.

The post The biggest benefits of Python, according to CKL appeared first on Cheesecake Labs.