Startups

Code Noob? Read This.

In order to found a tech-driven startup, one doesn’t necessarily have to be an expert in all things tech. However, if you are a non-technical founder, it is absolutely important to know the basic concepts because many tech decisions are business decisions.

But first, let us examine the three most common scenarios a non-technical founder is likely to find themselves in.

Scenario A: As a non-technical founder, you outright admit that you don’t understand the first thing about tech. This could put you in a weak and disadvantaged position and risks making you look unprofessional. 

Scenario B: You pretend to understand because you think your developer is a genius and accept whatever they say because you don’t want to look…well, stupid. This risks you giving them full power and losing control. 

Scenario C: You decide to learn the basics so that you are able to a) follow a discussion with the tech stakeholders, and b) make educated tech-related business decisions.

Out of the three scenarios above, Scenario C is the most desirable. Scenarios A and B may work under certain circumstances, but they can also spectacularly backfire and lead to expensive rebuilding, which is something a young startup could really do without.

Let us now move on to a few basic concepts which you need to be aware of, in order to at least commence a discussion with a technical stakeholder.

Native App vs Web App

Web Apps have evolved so much in recent times that sometimes, it can be hard to choose between web apps and native apps. In reality, there is very little difference between the two unless you are building something resource intensive such as a game or a VR app. The differences will largely become apparent only when it comes to the User Experience (UX).

Note: Do not confuse User Interface (UI) with UX. UI refers to the look and feel i.e. the outward design of an app, while UX focuses on gaining a deep understanding of users, what they need, what they value, their abilities, and also their limitations.  It also takes into account the business goals and objectives of the group managing the project. UX best practices promote improving the quality of the user’s interaction with and perceptions of your product and any other related services.

A native mobile app will have to be downloaded via a platform such as the App Store (iOS) or Google Play (Android), and is generally built to take full advantage of all capabilities on the end user’s device. A web app in contrast, is essentially a mini-version of a website itself.

As a non-technical entrepreneur, keep in mind that deciding between web development and mobile development is not just a tech decision but also a critical business decision. While it is possible to use native mobile apps and web apps to accomplish the same thing, your choice needs to take into account the current functionality of your app, the feature roadmap, and the user’s needs. You can learn more about choosing the right tech stack for your app here

Frontend vs Backend

Perhaps the most frequently used words in a developer’s vocabulary, the frontend refers to the code of the app running on your device, and it is responsible for:

  • Requesting information from servers
  • Showing the information in a User Interface (UI)
  • Obtaining user interactions

But this is only half of the story. There’s a whole universe underneath the surface — which is what we are referring to when we say ‘the backend’. The backend consists of all the code running on the servers. The backend is responsible for:

  • Talking with other computers
  • Storing data
  • Serving data when requested

The backend of an app communicates with the gazillion other devices connected to the internet through elements such as HTTP (which is a protocol, or set of rules, which determine how computers communicate), IP addresses (which is like a phone number used to identify a server where information is stored), URLs (web addresses such as google.com), and DNS (a service which matches IP addresses with URLs).

Database and Storage

Though these terms are often used interchangeably, they are in fact, two completely different objects.

The database is the know-it-all, the memory behind everything. It holds data in some predefined format. Storage on the other hand, is a place used to store a variety of data which may not even be related to each other (think code, images, videos etc.)

A good way to understand a database is to think of it as a group of connected spreadsheets, it is composed of a number of tables and they can all be connected. A classic relational data model looks like this:

This is what a database looks like / Credits: hackernoon.com

NoSQL

NoSQL is a type of non-relational database which became popular with startups due to its high scalability. Though it is referred to as a non-relational database, that doesn’t mean that NoSQL is incapable of creating relationships between different data.

If you are building an app which handles information you will be dealing with databases a lot. But here’s what you need to remember:

  • Relational databases tend to be faster, in some cases, but are much more rigid structures. This means that whenever you want to change the structure you might break the data consistency.
  • Non-relational databases, on the other hand, are a lot more flexible. You can change the relations every day and the structure will remain intact. It is for this reason that they are widely adopted by early-stage startups because in an MVP (Minimum Viable Product) the database structure will potentially be changing every day.

Unless you are 100% sure about the Database structure from day one you should have a structure that allows you to iterate with ease.

APIs

Recall the distinctions we made between the frontend and the backend much earlier in the article. Now, how do you get these two sections talking to each other? That’s where an API comes in.

An API is a common language which allows the backend and the frontend to communicate with each other, thus opening up the opportunity for you to connect your app to a vast variety of third party services.

An API or microservice based architecture, should you use it, will allow you to build different parts of your app in different languages, thus giving you the freedom to choose the best tools for each individual module. For instance, consider how LinkedIn is built. LinkedIn may have only one backend but several frontends such as a web app, and iOS app, and an android app. All these individual modules can easily communicate with the backend with the use of a common API.


That largely covers basics of what you need to know about tech as a non-technical founder, and we hope this information helps you make informed business decisions which can be critical for the growth of your business. By now, you should also be able to understand your technical stakeholders better.

If you can’t, the problem may very well lie with your technical partner(s) and could mean that they don’t know how to adapt their communication to suit their audience. In that case, you would probably be better off looking for a different technical partner to avoid running into bigger, much costlier problems down the line. 

Startups

The best of time or worst of times

A lockdown and a recession brought about by a pandemic sounds like the worst time to start working on a startup. Think again.

Cover image credits: Mind Cafe/Medium.com

He who has no dog, hunts like a cat” – Old Portugese Proverb

As we write this, the world is under lockdown. Large businesses are furloughing workers, and small businesses are shutting down. By all measures, it may seem unwise to contemplate or begin work on that MVP you have been thinking about for a long time now.

Or is it?
Baron Rothschild, an 18th-century British nobleman and member of the Rothschild banking family, is credited with saying that “the time to buy is when there’s blood in the streets.” He should know. Rothschild made a fortune buying in the panic that followed the Battle of Waterloo against Napoleon.

Similar sentiments seem to prevail in Silicon Valley too. Here’s a recent tweet by Paul Graham, the founder of Y Combinator.

https://twitter.com/paulg/status/1245292019318210560

At Calcey, we are also inclined to agree with these views. Here’s our reasoning.

Downturns create problems that entrepreneurs can solve

Recessions create a variety of new problems, and entrepreneurs are problem-solvers at heart. Technology-based businesses typically go through a period of product development and finding product-market fit while in their pre-revenue phase. An economic downturn makes it easier to find this elusive product-market fit, since customers tighten their purse strings, thus forcing actual pain points to make themselves visible.

Easier to put together a good founding team (while big companies shed workers)

A downturn can make it easier to put together a good founding team. It is a well documented fact that the most successful founding teams usually consist of mid-career professionals who walked away from their regular jobs, either by choice or by circumstance. Going by this logic, the typical mid-career professional tends to be paid handsomely while being employed at a  bigger, low-risk company during boom times. However, their handsome remuneration packages make them very vulnerable to layoffs during lean times,  when large companies look to trim their fat.

And the lean times will come as they have now, and you will find many hyper-talented, experienced individuals joining the ranks of the newly unemployed. At this point, they may be willing to consider co-founding a startup, something they would have never thought about otherwise. However, do remember that for talented individuals with enviable track records, unemployement is a very brief experience. As soon as the economy shows first signs of a recovery, they will be snapped up by larger companies. You have a small window to make use of this opportunity, but don’t ever try to offer them a bad deal. Instead, talk to them and see if they are interested. See if they will make for a good co-founder, and go ahead with the hire. 

You get to hone your business model in the harshest of conditions

Startups which succeed in finding product-market fit during a bear market often get there using a mix of ingenuity and a relentless focus on the product. The lack of VC funding and limited finances will force them to remain lean and agile, avoiding bloat and distractions.

Once the recession gives way to a recovery, these battle tested startups will find it easier to attract VC money. After all, it is hard to ignore the very convincing business case of a startup that convinced customers to part with their money during a time where they’d rather not.

Discipline and focus will become part of your startup’s culture

Frugality is one of Amazon’s 14 leadership principles. The company actively embraces frugality, claiming that “Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.”

This is very true. The most creative and innovative solutions are born when you have to make do with less. Just ask Brian Chesky and the AirBnB team, who ended up founding the lodging marketplace behemoth simply out of a need to make some extra money during the financial crisis of 2008. 

The AirBnB co-founders resorted to selling Obama themed breakfast cereal at one point, in a bid to make AirBnB work / Credits: Google

You bootstrap for longer, and end up with more equity

Startups founded during a recession are more likely to have been bootstrapped, and as a result, have no choice but to focus on achieving their revenue targets. Bootstrapped startups that make it out of a recession can afford to give away less equity to any potential venture capitalists, since the underlying business model is already generating cash.

Besides, with no immediate need for cash, you can take your time to carefully vet any potential investors, so that they end up being a good fit for your startup. 

You can build better, at a lower cost

During a recession, prices tend to come down and smart entrepreneurs know to take advantage of this. If you are building a technology startup, the costs of hiring external services providers is also likely to be lower, compared to what it would be during an economic boom. External developers and enterprise service providers would be happy to offer you discounts and better terms. What all this means is that you get to build your product for much cheaper.

It’s easier to gain someone’s attention

There has never been a moment in recent history where the entire world is at home, free from the many distractions which compete for our attention everyday. As a result, people will be in a better state of mind to listen to new ideas, ruminate on them, and actually respond. So, if you are thinking of pitching a new idea to a customer or a potential co-founder, this is the time to go for it. 

Isn’t that great?

If you are working on an MVP, a full blown app or something similar while on lockdown, why not give us a call? We are working remotely too, and would be happy to see how we could help!

Tech

Demystifying Redux: A Beginner’s Guide What Next?

A guide to understanding Redux Thunk, Saga, and Observables

Redux is an extremely popular JavaScript library which can be used to manage an application state. An extremely loyal friend to the React ninjas amongst us, think of Redux as the middleman between the frontend and the backend, whose job it is to store data temporarily. In this blog post, we will be examining Redux itself, along with its other components such as thunks, sagas, and observables.

Created by Dan Abramov, Redux provides a predictable approach to managing state that benefits from immutability, keeps business logic contained, acts as the single source of truth, and has a very small API. To use an analogy, if you equate Mario to React, Redux is what would tell the game how long Small Mario can remain in his Super form after making use of a Super Mushroom. The beauty of Redux lies in how easily it allows developers to scale a simple app to a large, complex one.

Redux is built on three main components, namely:

  • Actions: Payloads of information that send data from your application to your store. They are the only source of information for the store. You send them to the store by dispatching actions using the redux-connect library.
  • Reducers: Are responsible for modifying the store (i.e. state) according to the actions dispatched.
  • Store: Stores the whole state of the app in an immutable object tree.

The typical Redux app would have a single store with a single root reducing function. As an app grows, all you have to do is to split the root reducer into smaller reducers independently operating on the different parts of the state tree. This structure allows Redux to be simple yet powerful, because it is possible to trace every mutation to the action that caused it. You can even record user sessions and reproduce them just by replaying every action.

Redux Thunk

Remember, Redux is not an application framework, and does not dictate how effects should be handled. For that, developers can adopt any preferred middleware, and redux-thunk is arguably the most primitive of them. Redux-thunk is noteworthy in that it allows you to dispatch actions asynchronously. Written by Dan Abramov himself as part of Redux before being split out into a separate package, redux-thunk’s original implementation is tiny enough to quote in its entirety:

In simple terms, redux-thunk is a functional programming technique used to delay computation. Instead of executing a function right away, redux-thunk can be optionally used to perform a function later.  

See for yourself:

redux-thunk can also wrap calculations that might be slow, or even unending, while other code components can decide whether to actually run the thunk.

The key benefit provided by redux-thunk is it allows us to avoid directly causing side effects in our actions, action creators, or components. Potentially messy code can be isolated in a thunk, leaving the rest of the code uncluttered. Middleware can later invoke the thunk to actually execute that function. Employing a code structure of this nature makes it easier to  test, maintain, extend, and reuse all components in a given codebase.

But, while redux-thunk works well for simple use cases, it may struggle to handle more complex scenarios. This brings us to…

Redux Saga

redux-saga is a different kind of middleware which can be used to handle asynchronous executions, and is an alternative to redux-thunk which comes with the added benefit of being able to easily handle complicated scenarios. redux-saga works by listening for dispatched actions, performing side effects, and dispatching actions to be handled by the redux reducer. 

Because redux-saga relies on ES6 Generator functions, its code is simpler and more readable. However, asynchronous calls which would normally be directly inside an action creator in redux-thunk will have a clear separation in redux-saga.

The benefits of using redux-saga are many. Testing is much easier. The code is much more readable and test cases become simple without needing to mock asynchronous behaviour, thus making redux-saga a great fit to handle complex scenarios. However, redux-saga also brings in a lot of added complexity and additional dependencies.  

Redux Observable

redux-observable is the new kid on the block and can accomplish pretty much everything redux-saga can. Both are middleware. But, the difference between the two stems from how they operate— redux-saga uses the generator function, while redux-observable doesn’t.

redux-observable relies on ‘epic’, which is a function that takes a stream of actions and returns a modified stream of actions. You can think of an epic as a description of what additional actions redux-observable should dispatch. An epic is very much similar to the concept of a “saga” in redux-saga.

The benefits of redux-observable lie in its high function reusability and easy testing. However, in contrast to redux-saga, tests in redux-observable require mocking.

Which One Should I Use?

This is where things get tricky. As a rule, don’t bring in redux-saga or redux-observable before you need them. For most simple cases, redux-thunk will serve you well (and is very easy to learn, too). As the async becomes more complex, that’s when you should start thinking about bringing in redux-saga or redux-observable, because that is where they truly shine. 

And how should you choose between redux-saga and redux-observable? 

That, young padawan, is a balancing act. Our advice is to weigh up the pros and cons, and go with the one that promises a higher marginal benefit. 

Happy coding!

AnnouncementsNews

Gehan Dias joins Calcey as General Manager

We are thrilled to announce the appointment of Gehan Dias as General Manager at Calcey Technologies. Gehan joins us after having served as General Manager of LSEG Technology (part of the London Stock Exchange Group). Formerly known as MillenniumIT, LSEG Technology is one of the best-known success stories in the Sri Lankan IT ecosystem, having grown from a startup into is a leading provider of mission-critical, high performance, high availability systems to the world’s financial markets, culminating in an acquisition by the London Stock Exchange.

Gehan has spent almost 20 years managing large teams and delivering complex, multi-year enterprise projects. Aside from his time at MillenniumIT, he also founded one of the first mobile app development agencies in Sri Lanka – Appwolf – providing mobile app development services to clients around the globe. He holds a BA in Philosophy, Politics and Economics from the University of Oxford. 

Calcey’s CEO Mangala Karunaratne said, ‘We are thrilled to add Gehan to our team as we prepare for a period of aggressive growth. Despite the current challenges in the business climate, we expect the technology sector to thrive and perhaps even gain new momentum as digitization becomes a priority for all businesses. Gehan’s many years of managing complex projects and teams within a rapidly growing company are an ideal complement for our growth plans”. 

Gehan said, “I’m delighted to join such an outstanding technology company just as it is about to enter its next phase of growth. Calcey has a 17 year track record of excellence in the software industry and I’m looking forward to helping it to reach new heights.”

Welcome on board Gehan!