Shourya Lala

Notes on starting up

Sun, 20 Aug 2023 10:07:47 +0600

Become information consuming machines. The amount of relevant insights and upskilling opportunities you are exposed to in the early days of starting up is extremely high.

High development velocity without compromising on good coding standards is difficult but important.

Measure worth based on output delivered. Time and effort spent is inconsequential.

Your workflow is a constant tiff between Maker’s schedule vs Manager’s schedule - http://www.paulgraham.com/makersschedule.html.

A good engineer is a function of their pace of development + level of optimisation.

The number of people willing to provide unfiltered and exhaustive feedback to your product is usually always a positive surprise.

Indirect feedback channels reveal strong patterns if received in volume.

If your product has multiple features that users would be unfamiliar with, segment those features based on a user’s behaviour or reveal them progressively.

Frequent life-threatening challenges and constant ups and downs feel difficult at first but you surely gain a level of mental immunity after sometime.

“Over the years, I’ve come to see that the best programmer doesn’t add 10 times the value. He or she adds more like a 100 times.” - Reed Hastings This is especially more relevant when the number of jumps to reaching the end-user are few.

There tends to be an unspoken distance between employer and employee.

A 40 hours work week is a part-time job.

If you were a coder, continue to be a coder.

Every founder is a de-facto product manager. Every founder is a de-facto seller.

“Careers are dead. Every employee is an unrestricted free agent” - Mark Cuban

It is extremely easy to get busy. It is important to spend time on the right busy.

Major reason for your existence is your power to go faster than the incumbents.

Be a good builder. Be a good seller.

If hiring freshers, find individuals with an inherent passion for excellence in their vertical. The rest would lack a good work ethic.

Mutual respect and fostering an ownership mentality drives throughput far more than micromanagement.

Gaining back momentum once lost is actually very difficult.

Efficient sprints pre-emptively and pessimistically account for stakeholder timelines.

“Make error free production deployments a foregone conclusion.”

Building culture is similar to building SEO. Doesnt show results immediately but helps compound your growth in the long term.

Your moat should be built in-house. If you’re selling a better looking experience as compared to existing players, then the product should be designed inhouse.

Your ad can only have one call-to-action. Choose wisely.

Product and Distribution are yin and yang for a B2C. Equally tough. Equally important.

Habit building products are wildly difficult to build retention for.

Your tech stack is only as strong as your weakest third party plugin.

An incomplete team is better than a team of low performers.

Domain edge and conviction through numbers usually trumps silver tongue or emotional narratives while raising capital.

Building pathways to reach the right audience/tools/investors are extremely important to grow faster. Accelerators and incubators that provide this edge are worth the equity to gain that leverage.

Building in solitude rarely works out.

At some point, you move from an idea/product to a company. Outlook should change accordingly.

Market can be local but the tech should always be compared to a global standard.

Effective compartmentalisation and ability to context switch will go miles for you.

Onion World

Tue, 28 Sep 2021 10:07:47 +0600

As the lead simulation designer at Hypernova Reality, Max was considered one of the most talented architects in the organisation. But his latest project had proved to be a lot more demanding than he had ever expected.

This time, he was tasked with crafting an extremely pivotal clue, one that would bring the lower-order beings even closer to the acceptance. This was the fourth phase of a six phase story arc. Having played crucial roles in constructing the clues for the third phase, the pressure on him was higher than ever to deliver a great piece.

Max was a man of few words, preferring to let his work speak for itself. He spent countless hours in his office, pouring over code and designs, making sure every detail was perfect. This time he had chosen to hide the next clue in the discovery of a new particle, that he had playfully nicknamed the God particle. The project had consumed him, and he found himself working longer and longer hours, barely taking breaks to eat or sleep.

As weeks turned to months, the spotlight and awe around the project continued to grow, especially amongst his co-workers. People would whisper about him in the cafeteria in hushed tones, as if they were afraid to be overheard. When he walked into a room, conversations would stop abruptly, and everyone would turn to stare at him, avoiding asking him any direct questions.

One constant that centred him through all of this was Alicia. She was the only person that Max had grown close to in many years. Different people had adjusted in different ways to the events of the recent times. The world had grown increasingly solitary and she remained the only person who knew how to make Max open up. Lately, the project had been keeping them from frequently meeting each other.

One night, Max was working late in his office, working on the anthropomorphic variables that were crucial for the sim-phase-4 discovery. He was so absorbed in his work that he didn’t notice the door opening slowly behind him. It wasn’t until he heard footsteps approaching that he turned around.

Standing in the doorway was Elliott, the CEO & President of Hypernova. He was tall and imposing, with a constant stern expression on his face. Max felt a cold sweat break out on his forehead as the man stepped into the room.

“Max”, Elliott said, his voice low and menacing. “How close are we?”

Max tried to compose himself, but he was taken aback to see Elliott and didn’t answer for several seconds. Elliott walked over to Max’s workspace, his eyes scanning the frameworks on his desk.

“Looks like sim-phase-4 is shaping out to be quite interesting”, he said, his voice barely above a whisper. “What are your plans for the spacetime coordinates?”

“Planning to place it in sim-2012, in Switzerland”, Max replies.

Elliott gives an approving nod, his grim face slowly turning in an expression of assurance. He walked around the workspace as he took in more of the data.

“We’re reaching closer to letting them find out about us. Its an exciting time.” He says from the other side of the desk.

Max attempts to engage Elliott on the topic. “What do you think will happen when they do?”

He looks at Max and replies after a few seconds. “Same thing that happened to us, hopefully”. He gives him a rare comforting smile and starts to walk back out of the room.

Before leaving, he stops for a moment and turns back. “You know you should take a break from time to time. Do you have any plans after work?”

“Yes sir, I do. Going out with Alicia today to the phase-6 museum.”

Retail POS

Mon, 17 Aug 2020 10:07:47 +0600

To date, most of India’s grocery retail happens at small local stores (kiranas), accounting for 75-78% of the consumer goods market.

Most of these local stores only track their inventory on a batch level and do not digitize their day-to-day sales. That means that close to 75-78% of a $883 billion market is offline. This leads to challenges.

Downsides

Shopowners need to be conscious of their inventory and purchase stock based on what sells and what doesnt. This is usually done through intuition.
As all the sales of the day go un-invoiced, shopowners have a difficult time calculating their end of day profits and also managing their accounts.
Brands have a pronounced problem. They would like to understand a bit more about which pincodes or localities are the best selling for them. They’d also like to position their inventory ahead of their competitors, as with a lot of FMCG products, products unseen are products unsold.
Brands might also like to host targeted campaigns based on perceived interests. But they dont gain a granular understanding of specific markets, more of an aggregated understanding based on the goods sold to higher level distributors.

Roadblock

Big shopping stores, retail outlets and supermarkets tend to have a proper point-of-sale(POS) setup with bar code scanners and a computer with a local/cloud software for billing and invoicing. This is a luxury for kirana store operators who refuse to invest in such a setup despite the challenges.

Solution

A computer vision model trained on various FMCG products and fine-tuned on relevant local items with a client facing app posing as an advanced ‘item scanner’.

Product use-case:

A person enters a local mom-n-pop store, picks up items and approaches the billing counter.
The billing equipment is nothing but a smartphone on a stand. Shopkeeper scans the items one-by-one within seconds by pointing it at the app opened camera.
The app compiles the list of items and generates the bill based on pre-set prices for each item. Quantity of items will also be perceived by the app and duly factored in.
Final prices would be editable in case some changes are required based on customer requests or current offers.
App displays a final screen with a QR code that can be used for payment. Transaction is recorded. User shares mobile number at their discretion in case they want a copy of the receipt as an SMS.

POC

Attempted a simple image classifier by using transfer learning over an existing CNN model trained on consumer product images made available by Stanford research. (Tensorflow made it extremely simple to get started).
Model can be trained and refined on different verticals based on categories of items sold. This will improve accuracy and keep manual intervention to a minimum.

If core solution is accepted, this can further foray into becoming a SaaS, linked to other stakeholders like distributors or brands, extending this service into automated inventory fulfilment, store offers, credit-line etc.

Notes/Caveats

Requires the model accuracy to be strong and needs to be accommodative to new items being added to it.
Requires the interaction medium to be text-light and action-light. Most kirana store operators are technologically unsavvy and will approach this with low inclination.
Requires a library of items to be maintained with accurate prices which do fluctuate based on time and region.
Lots of nuance required to make it production worthy. Some shops sell various kinds of dal and loose condiments for example.

Implementation

Fine tuning dataset with sample images of local grocery items: https://drive.google.com/file/d/162CY0A6fyVOC4NZEWaq0b7zQJ23zjD41/view?usp=sharing
Code for using standford_online_products as base and building a specialised model using transfer learning: https://gist.github.com/shouryalala/215a7df39e9d8ec5fbe1c5d357d126e3
Code for running this model locally on an Android app: https://github.com/shouryalala/retail-pos

CRYB

Wed, 20 Mar 2019 10:07:47 +0600

Hyperlocal Home Assistance by empowering the overlooked

An app based, on demand solution for providing reliable home assistance for a diverse range of requirements, with a focus on diligence, creating trust amongst users and empowering assistants.

The core idea was to build an incredibly capable interface for engaging with an illiterate target audience. This would allow us to unlock more gig opportunities for this audience using technology, thereby driving more income.

Background:

4/5 metropolitan households rely on domestic help for daily household chores such as home cleaning, cooking, odd chores etc
There are over 50 million domestic help workers in India. Most of them women. Most of them uneducated.
The entire demand and supply exists on an informal economy with no structure for sourcing, vetting, or payments.
There is a distinct sense of dis-satisfaction on both sides - residential customers living in societies and gig workers who are averse to technology.

CRYB - Core Offering:

Simple vernacular UI for assistants who have a basic grasp of language.
Voice first - each text element had text to speech.
Built as an app for Android OS and KaiOS (lightweight OS used by $20 JioPhones).
Also supported a conversational interface via dynamic IVR - Assistants could use a simple T9 non-smartphone and call a number and press digits to engage in their local language.

More features:

Schedule management based on ongoing and upcoming work, location, and availability.
Full screen overlay over lock screen to drive ease of use - Reminder of upcoming work or a new job request would wake up the entire phone and put yes/no actions in front.
Dynamic request relaying - If a job request goes unanswered after multiple tries, the request gets forwarded to the next eligible assistant in real-time without customer hassle (similar to Uber searching for drivers)
Automatically raises volume if accidentally muted. Automatically alerts about phone low battery. Automatically alerts about phone internet recharge or no connection. Offline reminder mechanism even if internet not available. (These were added keeping the target audience in mind)
Rating mechanism, job history, payment history and income statement and such.

Expected outcome:

Assistants no longer have to solely rely on word of mouth to find new jobs.
Residents can leverage this added ease of requesting for help to get even more done.. eg: help with guests coming over in the evening.
Adhoc requests would mean that assistants can earn more income by utilising their idle time much more effectively.
Resident feedbacks, on-time presence, ratings, past work history etc will drive accountability and deter abrupt loss of job.
Standardisation in service would mean consistent pricing and better income.

Execution:

This product could act as a seamless plug-in for companies currently active in urban household service provider domain. This includes startups in the gated community management business or companies providing skilled labour for hire or even hyperlocal e-commerce.
Go-to-market as a standalone product also has advantages as societies act as small demarcated units with their own pool of assistants and hundreds of residents. This allows focussed marketing and agile scaling.
As this augments an existing service, demand supply flywheel does not need to get created from scratch and can in fact, onboard the existing network and grow from there.

MVP/v0:

A fairly extensive MVP was created with Java for the assistant client app and Node.js deployed on serverless Cloud Functions on the backend. A resident facing client app was also created using Flutter. The codebase for each exists here:

Code for the Assistant Client App: https://github.com/shouryalala/kanta-maid-client-app
Code for the Resident Client App: https://github.com/shouryalala/ria_client_app
Code for the Serverless backend: https://github.com/shouryalala/ria-server
Wannabe pitch deck: Pitch Deck
A no-frills demo of the entire product:

Periferi

Wed, 17 May 2017 10:07:47 +0600

Location based social networking.

Although attempted several times in the past, there are compelling upsides to online location based communities.

The primary motivation back in college was to build a network that capitalises on how institutions tend to have a high density of like-minded individuals yet dont have a platform where they can interact with each other about general happenings without sending each other a friend request.

On zooming out, there seemed to be many other places where this could have varying applications:

A bulletin board - Your local barista might be hosting a coffee making session or your distant neighbours might be hosting a garage sale that you might be interested in.
A hyperlocal social feed - Pictures from a rainbow you saw from your window; Major construction work being planned that you want to find out what the people from your pin code think about.
Local news aggregator - Earthquake that is expected to hit the local town; It’s 2020 and you need to urgently find out which local hospitals have oxygen cylinders available as your family members have been affected.

Core

This led to building Periferi - a location based social networking platform where users currently in the same geographic area can socialise directly and engage with the local active community.

Primary features of this network:

Periferi was purposely built to be open and unrestricted. Anyone in that geographic ‘periferi’ can share and comment on posts and scroll through other past posts.

Community moderated: Periferis are generated by the community users. This means anyone can mark a geographic area and request a Periferi around it. If one doesnt exist already and more than N people agree with this request, it automatically gets created, ready to be engaged in.

Recognized areas: Periferis/networks for a town/state/city/recognised establishments will already be available. If you are in multiple periferis based on your location, an intuitive pinch out/pinch in motion will land you in the periferi of your choice.

This allows a user to decide the expanse of the information that they would like to consume and how intimate they would like to be with their interactions. A user would interect differently with their local neighbourhood as compared to posting on a feed available to the entire city.

Attributes

A social networks’ success relies heavily on many esoteric factors. Periferi did theoretically check off several of those factors:

Number of people needed to make the feed exciting (Clustering Coefficient) was low because even smaller communities can engage locally. The network will not get stretched too thin if it grows one zone at a time.
By keeping Periferi’s open by default, it discouraged close-knit networks which didnt invite new users (low clique clustering)
The networks were centred to a geographic point, or an overall community and not to specific individuals and their followers. This meant that the network overall would be resilient to individual nodes getting removed (High structural cohesion)
The viral quotient that comes along with scale-free networks (networks following a power law) is missing in this network to a certain extent.

Implementation

This was an MVP meant to research how social networks work and to understand their complexities. The client application was built on Java as an Android-only app. The backend was deployed on serverless functions and the database was Firebase realtime database.

The pinch-in/pinch-out mechanism was custom built by using GestureDetectors on a SurfaceView class.
Google Maps SDK was used with a custom color filter on various geographic layers. Various Marker Drag and Click Listeners were used to build the ability to draw shapes on the map and get back the geocodes.
Social logins were integrated to acquire quality users. Scripts were written to pre-fill and pre-compose certain recognised Periferis.
Elementary level of engineering was done on the feed compilation based on the upvotes, the replies and the overall user engagement.
Codebase for the client app can be found here: https://github.com/shouryalala/periferi-client