-Most people would not describe Slack as a No-code tool or a GTM platform! But if you reframe
-what it does, how it can be used and its place in your technology stack it becomes a power tool.
-It can be your GTM product, at least for v. 0.01.
-Most people would not describe Slack as a No-code tool or a GTM platform! But if you reframe
-what it does, how it can be used and its place in your technology stack it becomes a power tool.
-It can be your GTM product, at least for v. 0.01.
Last year I connected with Bay Area startup that deployed its first three versions as an Excel spreadsheet. Plain old vanilla -Excel, with macros and a ton of customized features. The conversation with their CTO helped me cement my thinking about how startups can -use off-the-shelf tools and patterns to get early traction.
- -Slack was a natural target for this reframe. Here are five aspects of this ubiquitous tool that can be used differently.
- -No startup wants to build device or OS-specific solutions if they can help it. This might seem strange to call out, -but it is; Slack works out of the box, on all devices and operating systems.
- -Many employees start work on day one with Slack already installed on their mobile devices, on their laptops. No custom -installs, or readme. This means that you are delivering a service into a tool your customers, your employees and your -co-founders already know and love.
- -Sending messages from your other technology stack components to Slack is a great way to knit together your systems. Webhooks -and Apps are fundamental to the Slack value prop. Lever away. No SMS costs. Since Slack supports push notifications to all their -devices, you don’t have to do any work to send updates or messages.
- -Slack supports custom forms and workflows. This means it starts to drop into the no-code/low-code category of solutions. To see the value, -take a look at their library of templates and tools for Builder Tool processes. -This tool will let you build sample forms, and send them to Slack to try out. Once the user completes the form, slack sends the results -out to an endpoint.
- -- Simple JSON tools. -
-
- - Rendered in your slack channels. -
-
- This is a power tool that some slack users, usually when they are not familiar with the concept of command line tools, overlook. -Slack comes with command line options to do standard activities: ‘send a message’ etc. But it also supports allowing you to -build your own set of command line options.
- -- In any slack channel, type '/'. You will see a list of commands - you can use. These are standard. The money feature is that you - can extend this with some basic configurations and serverless function - to handle specific tasks specific to your business. -
-
- Finally, lets think in terms of ROI. The code you do not write, can be your most valuable product. Building a web application and all the -work needed to make it production, ready takes time, effort and money. Slack is stable, installed and secure. It might not provide the startup founders’ -need for branding and logo visibility, but is very cost-effective. Free is always cost-effective!
- -The replacement cost of Slack, if it’s reframed as a No-code/GTM platform that delivers value directly to your customer, can be substantial. The actual -savings depends upon your specific business and the number of developers you did not have to hire. Keep in mind that startups raise money to hire teams.
- -Slack in the place of React App; Slack as your Identity Provider; Slack as your cloud hosting provider (GCP or AWS). You will still have to write some API endpoints, -maybe a few Lambda or serverless functions, but that work will cost a fraction of what a full-stack solution will cost.
- -Now, if you tell your lead developer you want your first version to be a slack integration, expect to be punched, or at the very least gently ridiculed. -This approach will not get a whole-hearted YAAAAAA from your tech team. It will feel like cheating. In a way, this approach is cheating. Your first GTM is -a hermit crab living in the shell of Slack. It will not have your logo on it, but if it gets your team the learnings and starts the revenue flowing, it’s fine.
- -Again, this approach does not work for every startup, but it can be a healthy thought process to break the “…let’s write [expensive] code…” pattern of thinking.
- -- Slack is free safe to use, supports 2FA and enables audit evidence. - I recommend you configure 'Enable & Enforce 2FA' for your users. This - ensures that your users are secure, and the integration you set up is equally - protected. -
-CEOs and Product Owners have all heard this refrain!
- -It causes stress. It adds time to the roadmap and stresses out teams. This article is a quick exploration of this character trait of developers.
- -We do not do this to annoy. And we are not trying to slow down a project.
- -To understand why this pattern is so common, it can help to unpack the mind of a developer. While code is complex and sophisticated, the reason -why developers default to this approach is simple, if you understand the mindset of your tech team.
- -Most developers when faced with changing requirements will, at some point, mentally throw up their hands and option for a ground-up rebuild. i.e. a refractor.
- -There are three major factors putting pressure on developers. New cloud solutions & approaches, new vendors and products and new code libraries.
- -Example. In 2012 I attended the second Backbone.js conference in Boston. Backbone JS was a short-lived, but wonderful library that provides views, -models and controllers for the new patterns coming up with single-page applications (aka SPAs). This library’s lifespan was short-lived. Measured -in months. The evolution of libraries and frameworks like Angular, Vue and React supplanted Backbone.js within eighteen months.
- -Sadly, there was no Backbone.js Conf the next year.
- -At the time we all were using Underscore.js, a library for array and object collections work that had grown out of the New York Times Data visualization -team and their grants from the Knight Foundation. During the conference, a presenter launched a new library called LoDash (a play on the keyboard -underscore character). This new library took the patterns of Underscore.js and added browser hacks that added dramatic speed improvements. It was -lauded as a drop-in replacement.
- -I watched as developers learned about the drop in replacement value of this new library, opened their laptops, and hot-swapped the library. At a conference, -during a presentation! It was amazing to see how much developers love the new shiny and sexy library.
- --- -For reference, hot-swapping a library at a conference is not a good pattern.
-
One of the unstated reasons that developers recommend replacement is code complexity. It takes a lot of time to learn a new codebase, internalize -the patterns and then get comfortable enough to start making changes.
- -We are not lazy, we just always think starting fresh is easier, better, or faster. We do not want to own someone else’s code. We do not -(really) think they did it well. Developers love to curb-stomp the views developers work. My code is always better. :)
- -There is no simple solution. Being forewarned is the first step. Refactors come with their own unique set of risks. One approach is to request the -developer to provide a detailed assessment of the reasons why the current solutions are not viable. Detailed, is not a verbal summary. Forcing a -developer to take the time to outline specifics, can sometimes break the spell.
- -If you have a developer who catches themselves, and is self-aware enough of the trap and owns up to the emotional desire to start fresh, then you -have a keeper. Give that developer a title bump, and hold them close.
- -A second approach is to have the developer do a ‘replacement cost estimate’, using off-the-shelf options only. Force the developer to play devil’s -advocate and do the work to find existing solutions that could replace custom-built solutions can really help surface hidden issues.
- -This is not surprising. What master chef wants to work from another chef’s recipes? It’s no different for developers. We hate how other developers -name their files, name their methods and organize the classes. Hate is not too strong a word.
- -Almost all developers are smart enough to keep this fact hidden. We know it makes us look like snowflakes and a bit crazy. For non-technical -leaders, the idea that some code is ‘special’ and other code is ‘bad’ is a foreign concept. How would any business person know?
- -A final piece of the developer mindset; is that we always think we can build something better. We all know intellectually that the core libraries -we use are amazing. We know that code written and tested by thousands of other smart coders is always more stable and scalable. But we still will find -reasons to write out our ‘method’, and not use the ‘method’ already imported from a system package.
- -I have watched developer convince themselves that they need to build their own custom form validation class and ignore the Angular Form API, because -of personal desire to do it better. If a global survey was possible, I predict that most code bases have both versions in their code; loaded library method, -and localized custom version.
- --- -Custom code is never as good as code written and vetted by the crowd (open source).
-
Keep this in mind when you are faced with the statement: We need to refactor.
- -Expect to be told that the current solution, with customers and revenue, is no good and a full bottom-up rebuild is needed. Expect to hear about security -issues, memory leaks and testing problems. These are the tools of the developer who wants new tools, a new approach or simply just value their work more -than others.
- -The answer is that code serves revenue. Perfect code does not generate perfect revenue. No customer purchases a SAS product because the code was ‘clean’, -the API integration was beautiful and the CI/CD processes were 10x faster.
- -My recommendation is to simply do not respond. :) Smile and say nothing.
- -Developers are not children, but distractions work. Give a developer the option of a refactor, or a new and complex stack component to integrate, and you might -be able to redirect them long enough have get past the minefield.
- -The long & short of this concept is that you either have a very declarative data store that locks down fields and relationships or not. -In the end, the all work, and they store your data. In No-SQL you can data fields, names and structures on the fly, and handle the differences in code. In SQL -you have to do more work to change the way data is stored, but your code is -clear and more concise.
- -Here is a short reference list:
- -It might be surprising. Most startups think less about the impact of their application’s database than they should. Often this is the domain of the -first developer on site, the first tech hire or just the opinion of the most technical person around the founder. This is not startup laziness. It’s because -founders do not assign much value to the database selection.
- -The dirty secret about developers is that we rarely think about the impact of SQL vs No-SQL storage options. Sometimes we know both solutions -and deployed production applications in each. But often we know what’s new, what’s worked, or the storage option we like the most. Our technology -decision-making rubrics are not mature. At least not until we get to the VP Eng or CTO level.
- -It should not be surprising, but developers have favorite solutions. Their preferences are fine, but not when assessing patterns that will speed up ROI or long-term support costs.
- -Without getting in a ‘this’ database is better than that database argument, here are a few things to keep in mind.
- -a. Need Flexibility Most -If you do not know or can not know how your data will be stored, then go with no-SQL. It will give you more flexibility when you -don’t have specifics. Your front-end coder can solve issues.
- -b. Need Flexibility Less -If you do know how your data will be stored, and do not expect that new information -will dramatically alter your thinking, then go with SQL.
- -c. Known Security Concerns -If you know are going into a regulated space, then the category ‘full managed datastore’ is worth -exploring. In that case, focus on GCP and AWS fully managed options. or Snowflake.
- -SQL comes with schemas and structure, but there are patterns that can be used to move between solutions. Prisma.io is a perfect example. It makes schema, for either SQL/NoSQL approach a viable option. Additionally, solutions like Prisma, can help you scale load and costs in a cost-effective method long before you develop the technology team that will make better decisions.
- -- SQL or No-SQL. It has no impact on your SOC needs. Move on. -
-One of the easiest features to add to your applications and technology stack is -identity management. Identity is the information your application uses to manage -login, access and permissions. Getting your application up and running will require -you to choose to either store usernames and passwords in your database or delegate -this feature to an outside service.
- -The simplest approach is to just have your developer go with the standard approach
-and add fields to the database to store the username and password values for each
-user. While this might seem like a simple solution, this decision can have long-term impacts.
For the past ten years, the identity management industry has matured. Now this option -is simple to add to your application. Each of the major providers offers developer-friendly -documentation and SDKs (Software Development Kits).
- -A good way to think about this feature in your application is to look at other -solutions that offer services you do not need to build and scale your -business quickly. i.e. Paas as Ioc, CI/CD and cloud providers.
- -Adding identity as a service to our applications offers huge wins -as soon as you start to add your first group of users.
- -- They are not bad, but they open up security issues that your - application and team do not need to take on. Not having passwords in your - control, stored on your database, means that your team does not need - to be encryption and identity experts. -
-- Using a third-party identity provider can allow you to safely assert to - your customers and investors that your company uses the most current cyber - security patterns and best practices. Your business insurance can be lower - if you can provide you have 2FA patterns fully enabled. -
-So this is a big question. If you check out the marketing materials on the big providers, -you will get the sales pitch. The sales pitch is just that: Fluff + Promise + Cost.
- -A better way to think about this decision is to decide if you need a B2C or B2C identity -solution. A B2C identity provider is going to give you pricing assuming you have a larger -number of customers. A B2B identity will have pricing options assuming you have fewer -customers who might need more complex permission models. The leading vendors say they offer -both options, but in reality you want pricing that matches your specific user case.
- -B2C providers will talk about monthly active user accounts, while B2B will talk about -enterprise IDP and SSO options (in general).
- -Both of these vendor types will usually offer some identity options standard; Google, Apple, -Facebook etc. When you set up custom identity options for a large partner, then the costs -will change.
- -Why is this important? If your users log into your applications daily, then you care -about the total number of active users your vendors allow, and how they charge you as -your demand increases.
- -Hopefully, engaged and active users mean you have matching revenue. So as demand and costs -go up, your identity costs will go up. I recommend you think about and model these costs -on a per-user basis, and make sure it maps to your business model.
- -For example, my last startup required a combination. We offer B2B type identity options for -diagnostic labs and their staff you need to manage different aspects of their GTM -products on our platform.
- -We also had B2C-style individual diagnostic testing, so needed to allow a high volume -of individuals to access their medical test results. These users might share their data -with their company, but they own the data, so the pricing model was simpler.
- -We had a mix of both models and ended up having to select the B2C options. There are -options to have a blend of different providers, but its not simple.
- -Yes, you can. There are plenty of identity framework solutions to choose from. But this means -you are now in the identity management business. Your tech team will need to own the technology -and the subsequent sprint tickets to build and maintain.
- -The long-tail cost of building an in-house identity solution will show up in your SOC2 audits. It -will show us in your insurance costs, and it will show up in your training, hiring and roadmap -velocity.
- -Yes. Moving between identity providers is very possible. Not easy, but not terrible. There -are event solutions that make the transition seamless and can happen in the background, without -your customers noticing.
- -I have noticed that a decent percent of the startups and companies I have worked with have -done at least one, migration as they grow out their first use cases. The sales materials in -all the vendors will trumpet their solutions as perfect. The reality is that business needs -change.
- -If you want more details there are two concepts to research, RBAC (Role-Base Access Control and ABAC Attribute-based Access Control. -This can sound like a be a bit of a computer science concern, but understanding this concern will be expected to -organize your permissions can have a long-term impact.
- -
A new entry into the identity space, Wristband.dev has built on the security -benefits of giving their clients the option to start with the attribute-based access control -approach. The TL;DR is that ABAC is a bit harder up-front but much more valuable for a company -over time. Wristband makes it turnkey-easy.
- -Long term your SOC team will value ABAC more. And it will lower your security risk and lower the -cost of your audits.
- -1. Improved User Management Solutions
- -There are two trends in identity providers that you might want to think about. The first generation of -identity providers (Auth0, Cognito etc) offers decent SDKs but has some hidden roadmap costs. Customers often -had to do deeper integrations to get more advanced user management features.
- -For example, if you have failed 2FA setup for a customer, you can log into the Auth0 Admin console to -reset or remove a given set up. Long term teams add these integration points to their roadmap’s, because -giving the entire customer support team access to the identity provider admin console is not a supportable -approach.
- -AWS Cognito is famous for its lack of user management features. The AWS console lacks the UI tools -that Auth0 provides. As the number of customers using your application grows, your customer support teams will start -to demand better ways to address user authentication issues. If you are going with Cognito, triple your integration -time estimates.
- -2. Custom Permission Setup in the UI
- -The new generation of providers; FrontEgg and Wristband, provide more advanced SDK features that address -these user management features. Their APIs are more robust. And they offer more robust permission models that -can be dropped into applications. Their frontend UI SDKS have drop-in UI elements that allow B2B customers -to define their roles and groups. This feature allows these customers to customize your B2B application while -deploying their organization’s cyber security requirements. This means you are not imposing a one-size-fits-all -security model on all your customers.
- -These new providers have learned from the customer issues and added features that dramatically enhance -Zero Trust patterns. (This is a topic for a different post.)
- -Reach out if you have questions. Identity is an often overlooked and delayed feature.
- -Much like the selection process of SQL vs NoSQL, where to put your front-end application can be -a minefield. It can build in costs that are not needed, speed up or slow down deployment -and is often driven by the experience of your developers.
- -This is not a comprehensive list, but is a good sampling to open up some -options that are free, scalable and easy to use. Yes, you can split your API -hosting from your UI hosting.
- -Github.com is rock solid. When Github has an outage the entire world knows it, because -we can not get to our code or deploy. The GitHub servers handle millions of transactions per second. -Because of this base capability for hosting git repositories, their hosting services -for static content are extremely table front-end applications.
- -What Github Pages does not offer is serverless functions, which just means your backend -code (API endpoints etc) needs to be hosted somewhere else.
- -We often think of Github pages for blogs and code documentation, but it supports CNAMES and -domain Apex records. It also provides SSL certifications by default to enable HTTPS.
- -Heroku is Amazon Web Services (AWS) but with a devOps-free wrapper (or it was). For many years -this was over powered solution for hosting a front end. It has a strong CLI and works well with -deployments from CI/CD processes. It is a bit long in the ‘technology tooth’. It’s been around a -long time, and since Salesforce purchased it, the hobby (free) options have gone away.
- -Render.com is the new hotness! It’s the best of all the edge hosting options but with a strong -focus on the skills and challenges that front-end developers know the best. And it offers a free layer, for public repositories. -Since most starts do not have enough initial load to trigger the payment levels, it’s a great place to build. Their -setup process works well with GitHub Actions, and your developers will find the deployment process mirrors their development -tooling processes.
- -Fly.io is a docker-centric hosting solution. This option has a strong hobby pricing option, -so unless you exceed 5$ a month, it’s free. And most early-stage startups, this is a great solution. This solution -is great if you expect your team to need microservices or to move toward Kubernetes.
- -Vercel is designed for hosting UIs on the edge cloud. It’s designed to work well -with the specific configurations needed for front-end apps. NextJS works out of the box. Their jump-start -libraries make spinning up UI solutions an easy learning curve.
- -While Github.com is my go-to, for now, Firebase Hosting has been my -default for a while now. It’s turn-key easy. It works well with CI/CD processes, and can even be deployed directly -from your laptop if you want to get changes live quickly. You can use just the hosting service, and -ignore all the other GCP goodness. You can mix and match the solutions that site under the umbrella of Firebase; -auth, functions, hosting, AI etc.
- -- All these options are secure. For the past five years, SSL certificates have - become free and standard. So no cybersecurity concerns with using any of these. If - your deployment processes are managed from git repositories, then it's very solid. -
-* AWS EC & CloudFront -Why, why why :) Most websites do not need load balancers and CDNs. The cost of DevOps does -not outweigh the other options above. Both AWS and GCP best practices lead startups to -over provisions long before business or scale is an issue. Scaling back can be painful -when a startup needs to cut cloud costs.
- - - -