Subscribe to Our Blog Stay up to date with the latest tips and news.
Filter By:
Sort By:

Praveen Seshadri

Praveen Seshadri
Praveen is CEO of AppSheet and full-time coder. Over his career, he has pursued the "dream" of declarative end-user programming in various incarnations. In a previous life, he was a CS professor at Cornell University. And in another previous life, he was a partner engineering manager at Microsoft in the SQLServer and Bing teams.

Recent Posts

AppSheet Acquired by Google Cloud

Dear AppSheet Community, Today, I’m pleased to announce that AppSheet has been acquired by Google and will be joining the Google Cloud team. Before I explain why this is the right step, I want to be very clear that our customer-centric focus will not change. We have built relationships with you, in some cases over many years. I know many of you personally. We value these relationships deeply and we will continue to invest in, and broaden our relationships with you. With that said, I would like to share the most important details: The AppSheet services you use will continue. In fact, they will grow and expand once we integrate deeper with Google Cloud.  Our team is joining Google Cloud and will continue to run our service. We will continue to support customers—new and existing.  AppSheet will continue to work cross-platform. While we have always integrated deeply with G Suite and Google Cloud data sources, we will continue to support and improve our integrations with other cloud-hosted data sources like Office 365, Salesforce, Box, Dropbox, and databases hosted in other clouds. And while the majority of our mobile app users run on Android, we will continue to support and improve the way our apps run on iOS and on web browsers. Our core mission is unchanged. We want to “democratize” app development by enabling as many people as possible to build and distribute applications without writing a line of code. That continues to be our mission, and it aligns well with Google Cloud’s strategy to re-envision digital transformation with a business-user-centric application platform. Why does this acquisition feel like the right next step? First and foremost, we are philosophically and strategically aligned with Google Cloud in a shared commitment to a no-code platform. The AppSheet platform has been live for more than five years. As we’ve matured, so has the IT industry, and there is now a tremendous pent-up demand for enterprise automation. With the rise of low- and no-code platforms, citizen development has emerged as the strategic way for modern organizations to invest, innovate, and compete. As we engaged with various leaders in the Google Cloud team, we found to our delight that Google Cloud shares our commitment to a no-code platform. Like anyone who works in the technology industry, we admire the amazing, innovative technology that Google has created over the last two decades. There is great potential to leverage and integrate more deeply with many of Google’s amazing assets like G Suite and Android to improve the functionality, scale, and performance of AppSheet. Moving forward, we expect to combine AppSheet’s core strengths with Google Cloud’s deep industry expertise in verticals like financial services, retail, and media & entertainment. For more perspective on what this means for us together, you can read the blog from Google Cloud’s Vice President, Amit Zavery. In short, we can now deliver a better platform for our customers and reach and empower many more users. There will likely be a period where we have to settle into the new environment before forging ahead, but you should start seeing the benefits of today’s announcement soon. It is an exciting time for all of us at AppSheet. I appreciate your continued faith in us and I know we could not have reached this stage without you. Our journey together continues and I look forward to it. -Praveen

AppSheet 2018: The year in review

2018 in Review  Thanks to all of you for a great year. In the past 12 months, app creators around the world have been busy creating over 260,000 new mobile & desktop applications. That's a new app created every 2 minutes—quite amazing! We are fortunate to hear some of the ideas and see some of the thought and innovation that lies behind these apps. Here are some inspiring customer stories. Our team has also grown with some really great new additions to the AppSheet family—both full-time at our offices in Seattle and also part-time from around the world (Aleksi, Reza, Steve, Lynn). More than ever, we care about being a personal, responsive team. We added Intercom messaging to most of the pages on our site. It can be overwhelming at times dealing with thousands of "live" conversations a month, but we also learn about things we can do to improve the customer experience. We end the year with more than 12,400 members in the AppSheet User Community. With almost 600 posts and 2,600 comments a month, this is a vibrant, engaged, and supportive group of enthusiastic platform advocates. This community is a central part of our ecosystem and although Google+ is being retired in 2019, we'll find an alternative venue to keep it growing.  It is difficult to summarize all the platform changes over the year. We release a new version of the platform every day. This incremental change is a central mechanism for platform stability, but it can also be somewhat deceptive because we never have a "big new release". All the same, day by day, the platform has grown in functionality across all facets: app creation, data sources, app expressive power, UI richness, workflows, device install, management features, enterprise capabilities, and initial forays into intelligence and AI.   This year, we also started a new customer-facing app to capture feature requests—and it has been great to see the reaction. While it is not the exclusive way we prioritize work, votes from all of you play a very important role. There are now 385 unique feature requests across 6 different categories, and more than 1,000 votes for these features.  Which means, we are certainly going to be pretty busy next year! To learn more about our plans for 2019, look for a post in the first week of January. Until then, happy holidays and see you in the new year! 🎉     Apps Deployed in Over 180 Countries Apps created, tested, & deployed to users around the world   Most Popular Sample Apps Explore & copy sample apps to get your project started Inventory Management Timesheet Order Capture Equipment Inspections Sales Report Project Planner Store Inventory Field Service Log Shipment Tracker    Most Common App Use-Cases Every app is unique, but many fall into similar categories   New Platform Features Some of the favorite features added this year (make requests here)  ● Use Natural Language to Spec Your App  ● Quickly Edit Data Throughout Your Apps  ● Integrate with Zapier (Beta)  ● Integrate with Amazon Cognito  ● Pull to Sync App Data  ● Create Sliding Actions  ● Access the AppSheet API  ● Add KML Layers to App Maps  ● Add CONTEXT() to your Apps  ● Scan NFC Tags  ● Suggest Form Values Automatically  ● Build from On-Premise Databases   ● Add Events to a Calendar View  ● Integrate with Data Stores      Record Breaking AppSheet Growth AppSheet recognized as a 'Low-Code Leader'      Interested in Building Apps in 2019?    

PowerApps vs AppSheet: an in-depth comparison of no-code app platforms

No-code app platforms allow business users to create apps without writing code. There are many vendors with offerings that are labeled “no-code”. This article describes a framework with six criteria used to evaluate and benchmark these offerings. The article uses these criteria to evaluate and compare the two leading no-code app platforms: Microsoft PowerApps and AppSheet. Who is a Business User? Our focus is on business users rather than software engineers, programmers, or IT personnel. A classic business user works in some line of business in the organization (small, medium, or large organization), has an existing full time job, is comfortable with the consumption of desktop, web, and mobile technologies, and is competent with tools like Microsoft Word, Excel, PowerPoint, Google Docs, and WordPress. Often, business users will interact with cloud-based productivity systems like Salesforce, Workday, ServiceNow, Jira, Trello, Hubspot, etc that may be managed by their own teams or by a central IT team. Worldwide, there are many more business users ( ~1.5B) than developers (only ~15-20M). Platform Tenets This article considers app platforms that support business users who create and deploy their own apps to their teams (colleagues, vendors, etc) to improve business productivity. Such platforms must conform to certain tenets: No-code: These platforms have to cater to the business user audience who is not trained to code. Integrate with business data: The apps must work in an existing business environment and therefore integrate with existing business data. Work across devices and form factors: Not only must the apps support various device form factors, they must also run on various app form factors (web, mobile app, chatbot, etc). Implicit Criteria As we compare no-code platforms, there are two implicit subjective criteria that apply to all features and functionality. Expressive power: It is important that the apps can be rich and support a range of business functionality. Ease of use: Features should model intuitive user concepts (the way the user thinks of the problem being solved) rather than force the user to understand technical platform concepts. Comparison Framework We evaluate PowerApps and AppSheet along six technical dimensions. Data architecture Design for scale Security model Behavior description UI configuration Authoring environment 1. Data Architecture: PowerApps Business apps need to connect with business data. PowerApps is integrated with Microsoft’s Common Data Model that shares a data connector framework with other Microsoft tools like Power BI and Flow. As a result, connectors to most common data sources are available. This is a strength of the platform.  Every business app needs to be able to run offline or at least occasionally disconnected. However, the PowerApps architecture is implicitly connected. If you want the app to work disconnected, you have to set up local tables and manage data loading yourself via code. That is described at length in Microsoft’s documentation. This leads to ugly “code” like this: Unless you are a developer, you should steer clear of such logic. And even if you are developer, it is completely non-trivial to debug such logic and determine when it should and shouldn’t be used. Yet at the same time, the apps do not behave seamlessly when connected. It is common for apps to tell their users when there is newly available data. However, PowerApps does not automatically provide this functionality. Instead, this is the responsibility of the app creator. As described here, the recommended design is to use code to create a second data source to the same data, set up a background timer to repeatedly fetch the data, do a data diff by comparing data counts, and if so, show a refresh icon. Further, this timer has to be placed (but can be hidden) on the ‘current’ view, or else it will not run. The problems with this design are too many to list here, ranging from correctness to performance issues. This design choice also impacts operations like bulk update of multiple rows. This should be a standard operation in business app platforms. In PowerApps, you have to write code to do this. You have to keep your own “copy” collection of updated records and then you have to copy these back over into the original dataset. This is really a fragile design. The app is doing a “shadow copy” rather than updating data in place. It is not clear what happens to formulas that run at the same time: Do they work on the original data or the shadow copy? Summary: While the breadth of data connectors is a strong positive, the data architecture of PowerApps itself assigns too much responsibility to the app creator. In comparison, while AppSheet has fewer builtin data connectors, the platform automatically provides offline support, data synchronization, concurrent and bulk update capabilities.  2. Scale: PowerApps Apps often have to work with moderately large data sets (10,000 rows or more). In some cases, the data sets may be much larger but each app user may only need to see a smaller subset of the data. In PowerApps, all the data used has to be brought to the device, so to be efficient, the developer has to create filters that reduce the number of rows in each table. This is called “delegation” and is described here. PowerApps tries to be efficient with the delegation filters by “pushing” them to the data source. For example, if the data source were a SQL database, PowerApps will try to convert the request into a SQL query so that only the (hopefully small) result is brought back to the device. However, there are two problems with this: Not all data sources support filters. For example, many spreadsheets do not. Data sources do not support _all_ filters. In these cases, all the data is brought to the device and then filtered locally. This should still lead to a correct (though perhaps inefficient) result, except that PowerApps arbitrarily limits the number of rows that can be fetched per table. The limit is 500 rows (though recently, they have announced an increase of this limit in some cases to 2,000 rows). This has the effect of both producing arbitrary truncation of results but also incorrectness when there is logic that is based on the data. A more appropriate and scalable design choice would have been to filter data at a cloud-based web service and then send that data to the device. Under no circumstances should data be truncated. Summary: If you use PowerApps, make sure your apps use small data sets. In comparison, AppSheet apps can scale to significantly greater data sizes, limited primarily by the storage capacity on the device. The Security Filter mechanism is similar to the "delegation" concept of PowerApps, but more powerful. The Data Partitioning mechanism allows apps with very large data sets to still be supported. 3. Security: PowerApps Mobile business apps should be able to enforce security at two levels: (a) through authentication -- i.e., signin, (b) authorization -- who can use the app and do what with it. In PowerApps, authentication is exclusively handled via Active Directory. This is good because it integrates with the standard authentication mechanism used within many organizations. However, this is not so good if you want to use an app with anyone outside the organization (e.g., vendors, partners, etc). This turns out to be one of the major sources of dissatisfaction among the PowerApps user community. Authorization should be simple and transparent. For PowerApps, you authorize different classes of users based on their group membership in Active Directory. By itself, this is sound design if PowerApps were to handle it natively. However, in order to implement this authorization logic, you will end up having to write complicated code as described here. You set up an Active Directory custom data connector. Then you manually pull group membership data into the app as a local table. Then you check this data to see if a specific group is present and if the current user is part of this group. So in effect, groups and roles are not used as a security model at all. Instead, the security model is implemented by your code and may have loopholes if your code doesn’t get it exactly right. Summary: Security should be built into the platform rather than bolted on via code. In contrast, the AppSheet platform treats security as a first-class concept. Apps may require sign-in but the users may be within the same domain or outside the domain. No procedural code needs to be written involved in setting up or enforcing security. The app creator has control over data security at the row level, and also over actions at the row level. These security controls can be conditional and data-driven to provide rich dynamic security options. 4. Customizing App Behavior: PowerApps Most apps require dynamic behaviors that can be customized by the app creator. In a no-code app platform, you should expect common behavioral patterns to be easy to express in an understandable and logical manner. PowerApps provides two mechanisms to control dynamic behaviors --- spreadsheet-style formulas and procedural code. Formulas are widely used in PowerApps and they provide a powerful yet declarative mechanism for behavior. We really like and approve of this design choice! Where formulas are used, they conform to the spirit of a no-code platform. However, where code is used, it often results in brittle and opaque behaviors. Here are two examples: Deep linking is a common concept used to launch an app into a specific state. For example, a sales app might be launched with a deep link to a specific customer record. In PowerApps, this is not easy to control. The way to do this is to add an arbitrary query parameter to a link, then add an onStart timer to the app that looks for this query parameter, and if so, invoke a Navigate() function to go to a specific screen/view. In other words, you design your own deep links and you implement them yourself in code. Data capture forms often have custom logic that determines how to prepopulate a new row, how to branch based on initial answers, etc. Most form builders provide simple high-level mechanisms to define such logic. In PowerApps, this has to be done in code. Each form has a number of different events defined and each needs custom code to control behavior. Summary: We really like the emphasis on formulas even though the procedural code extensions make things complicated. The AppSheet platform has similarly embraced the use of spreadsheet-style formulas. In fact, if anything, formulas in AppSheet are more powerful and more ubiquitous, controlling computed columns, form logic, localization, actions, workflow rules, and much more. 5. UI Flexibility: PowerApps Of course, you need to be able to choose and configure mobile-friendly UI for your app. Some standard display patterns are really easy in PowerApps. For example, this article shows how to use a Gallery control. There is unfortunately no map control, which is a serious limitation at the moment. The default layouts can be customized via a drag-and-drop editor. While this adds flexibility, it also becomes the responsibility of the app creator then to ensure that the new layout works well on different device form factors. You can also define your own custom controls, but while this sounds powerful, it turns out to be a _lot_ of custom code for basic functions. This article describes how to build a confirmation dialog for a Delete operation. You have to build every element of it, lay it out and then hook up the events. Just like in Visual Basic. You have to define how to connect it with search, with sort, how to highlight the current item, etc. And you have to style it separately for iOS and for Android. That is a ridiculous amount of effort for a confirmation dialog. Summary: The flexibility adds power but takes a lot of work. The AppSheet platform consciously makes a different decision. Users can pick and configure broad display patterns, but cannot layout individual display elements. While this is less flexible, the platform can ensure consistent behavior and performance across a variety of form factors. 6. Authoring Environment PowerApps provides an authoring environment with an emulator to see your app as it is being built. While the environment is powerful in what it can do, it is very complicated for a new user. Of equal concern, it is also very slow and these performance issues are a significant source of dissatisfaction in the PowerApps user forum. Summary: An authoring environment for app creators should be intuitive and performant. Performance improvements will greatly enhance the experience. In contrast, the authoring environment of the AppSheet platform integrates the end-to-end capabilities of app creation, deployment and management into a single intelligent dashboard that suggests next steps, identifies opportunities and steers the user towards successful outcomes. Summary: PowerApps PowerApps is an evolving platform. While we expect some aspects to improve, some of the core architectural decisions have already been made and will be tough to change. While simple apps can be built in a no-code fashion, it is more of a framework for software engineers to build apps by writing code snippets in a stylized way. The data architecture and scale are matters of serious concern and we do not believe these concerns will recede in subsequent versions. They are a direct consequence of architectural choices of the platform. The security model has limitations at the moment, but these issues can be addressed. The behavior model based on spreadsheet-style formulas is by far the best aspect of the platform design. If Microsoft stays with an enhances this aspect of the platform, that will enhance the platform. However, the code-based behavioral extensions seem hacky at best. The UI model provides the potential for rich and flexible UI. In subsequent versions of the platform, we hope to see more standardized UI elements introduced so that app creators do not have to write code for common UI patterns. Finally, the authoring environment is sluggish and unnecessarily complex. As you evaluate PowerApps further, make sure to consider product reviews like the following: Also, read case studies like this article from Microsoft’s own IT department describing how they build internal apps with PowerApps. They use an entire dev and design team and a waterfall design process to build these apps. While they have been successful, I believe it is a true reflection of the product and that it targets a traditional IT-based development team rather than a citizen developer.  You should also consider alternatives. Most mobile apps that you’d be able to build on PowerApps are built easily on other no-code platforms like AppSheet, or on low-code platforms like Mendix or OutSystems. If you find positive reviews and happy customers for another app platform, you’re unlikely to go wrong. Good luck and much success in your app making. Summary: AppSheet The core technology in AppSheet differs from PowerApps in one significant way --- it is firmly "no-code". Everything that the app creator specifics is understood by the platform. While this limits some flexibility, it allows the platform to be intelligent, guide and help the app creator. This reflects in significant gains in simplicity and productivity.

How a Chef, Farmer, Pig, and an App Made Farm-to-Fork a Reality

Food loss continues to be one of the biggest problems impacting the global food industry, resulting in hundreds of billions of dollars of lost revenue each year. According to the United Nations (UN), at least one third of the food produced for annual human consumption (1.3 billion tons) gets lost or wasted. Consider this, though: The UN also claims that if you were to reduce just one fourth of the food that gets wasted annually, you would have enough left over to feed about 870 million people. This is an attainable goal. As an industry , it’s time we come together to eliminate waste and improve efficiencies. And technology — specifically apps — can play an instrumental role in making this happen. Why does so much food go unused? Food loss stems from a variety of different causes such as overproduction, rising quality standards, premature harvesting and consumer waste. Many of these challenges are beyond our control right now. There is one major issue, however, that can be immediately addressed which is the lack of real-time communication and visibility across the highly-fragmented food supply chain. Farms and fisheries, restaurants, warehouses and distribution centers are all collecting data on their own, but most of it is living in stagnant spreadsheets. Businesses need to put this data in motion by pumping it into apps that make it easy for end users like employees and supply partners to access, visualize and understand. Easy solution: More apps One way that businesses in the food industry can improve efficiencies and eliminate waste is by using apps. Apps can be used for a variety of important communications purposes, ranging from intelligent purchasing to fleet management and route optimization to scheduling and reporting. What’s amazing, too, is that you no longer need to know how to code — or shell out hundreds of thousands of dollars — to build a high quality business app. Now there are low- and no-code app maker platforms that you can use along with the data you already have. You can design a robust app in as little as ten minutes, even with little to no experience. So businesses of all sizes, even small restaurants and farms, now have access to affordable apps. CHEF514: Enabling farm to fork at the hyperlocal level One company that has had great success with an app maker platform is Montreal’s CHEF514, the brainchild of app maker Thibault Renouf. CHEF514 is an app that brings together local farmers and connects them with chefs in their area — reducing long-haul food shipments, which produce a lot of waste, while also helping small farms get their produce to market. As Renouf explained in a recent interview, there is massive consumer demand for local food. 77 percent of consumers, for instance, are actually willing to pay more for local produce. And there is even strong interest among chefs in Montreal to offer local food. The challenge for many chefs, though, is finding nearby farms to consistently do business with. “I have spoken with countless chefs and owners who recognize the demand for local produce, but can’t easily connect with nearby growers in their towns or provinces,” explained Renouf. “This is what I am actively changing with CHEF514 — a restaurant app, built with AppSheet, that helps local farmers in Montreal to connect with chefs and bring their products to market in one centralized place along with fresh data, pictures and contact information.” A labor of love In many ways, CHEF514 is a labor of love — a “bootstrap” project with only a few team members. When the company first launched, Renouf didn’t have an app. He was simply communicating with local growers, asking them to enter data into spreadsheets and exporting the information to restaurants over email. This worked fine at first, until it became apparent, based on feedback from the chefs he was working with, that an app was needed to organize the data more effectively. This posed a big problem, as Renouf didn’t know how to code or make an app! Renouf didn’t have a budget so instead of hiring a developer, he went to the Internet, searched for no-code app platforms and wound up selecting AppSheet. The app changed everything Using the platform, Renouf transformed his large database of farming information into a fully-functioning app that chefs could use to browse the local produce market. Here’s how the process works: Every week, Renouf simply sends out a newsletter reminding farmers who are using his service to update their inventories with information they want to share like prices, pictures and product descriptions. Then, he uses a Google Sheets add-on, Sheetgo, to consolidate the disparate spreadsheets into one master document which syncs with AppSheet. Inside of the app, chefs easily navigate between different screens displaying vendors, products with detailed descriptions and even specials. There is even a map that shows where farmers deliver their produce. A win-win for farmers and chefs “For farmers, all they need is an Internet connection and a Google account to use the service,” explained Renouf. “So it’s a very simple way that they can grow their business and expand into new markets. And for chefs and restaurant owners, the app eliminates the need to travel around to physical farmers markets or cold call businesses.” This is very important, as his end users are busy farmers and chefs who have a lot of other responsibilities on their plates and need to take care of this process quickly. One chef that is currently using CHEF514 is Andrew Gray of Montreal’s Café Guererro. “For me it has been a fantastic experience so far, as I have been able to get a couple of contacts from local producers,” Gray said when I asked him about his experience using the app. “I have been using it for almost 2 months. I have discovered a local pig farm, and now have an entire pig delivered to the cafe every 2 or 3 weeks. We butcher the whole animal, which has been a lot of fun.” Andrew also spoke about the experience of meeting and interacting with local farmers. “I met a great farmer, Mathieu, who delivers produce on a weekly basis,” he said. “His produce is beautiful — super fresh and really flavorful. Also, it’s very reasonably priced (as is the pig). It has been great to offer our clients local produce, and they enjoy it a lot as well. So it has made our business better. Plus, the app is very easy to use, too. I love how the producers have been divided into different categories, which is very helpful when searching for products.” Every restaurant can benefit from an app One of the most interesting parts about what Renouf is doing is that he is proving that there is a market and a need for the services that he is offering. He is taking unique data, and using it to build digital pipelines between chefs and local farmers — something that had not previously existed. It’s hard to overstate the value of this type of service for the global food industry. “I would have never thought of tackling something like this without the help of a no-code platform like AppSheet,” said Renouf. “An app maker platform gives you the freedom to act like a technology company, without having to go out and hire someone who knows how to code. It’s a truly game-changing service.”  

AppSheet platform directions in 2018

Happy new year! As usual at the start of the year, we share our plans for the platform and the directions we expect to take. For some context, take a look at the plans we described a year ago—as it turns out, we did deliver on many of those themes, although perhaps our original timeframes were overly optimistic. The goal of the AppSheet platform AppSheet is a platform for anyone to build, distribute and manage apps. That mission statement is intentionally broad and it has not fundamentally changed in the last three years.  We pursue this platform goal along three axes: Who? We really want _anyone_ with any technical skill level to be an app creator. We fully recognize that our platform currently requires a reasonable level of technical sophistication. We expect to take major steps to lower the barriers and make the platform more accessible. What? While we eventually expect to be able to create all apps, our current focus is on business apps. We define an "app" broadly, going beyond the confines of just a traditional mobile app but also incorporating a variety of merging app form factors as well as any aspect of logic + data + processing that is relevant to solving business problems. How? The platform should be end-to-end, enterprise-grade, and intelligent.  From the goal to product plans Our product plans always include work across a variety of areas: We rearchitect and rework our existing platform and model: for example, in 2017, we rebuilt much of the app editor,  replaced built-in actions with explicit Action definitions, and updated Google authentication on Android. We enhance the existing features: for example, in 2017, editor changes, stable app versions, new functions, and expression performance improvements. We add new features: for example, in 2017 we added XY and Video column types, Scheduled Reports, Push Notifications, Chatbot Apps, Deep Links, searchable audit logs, MySQL databases, teams, enterprise policies, and a lot more. We do an occasional bold new thing/moonshot: for example, in 2017, we did Chatbot Apps.   The actual features chosen are primarily influenced by the tremendous volume of direct feedback we get from our customer community. I personally read about 400 customer communications every week. We also pay attention to what is happening more broadly in our industry, and what we learn from advisors and analysts. Finally, our team tries to step back from the details occasionally and ask if there are fundamental improvements that can help our broad customer base.  From product plans to feature deployment Our engineering process is designed to minimize overheads and balance rapid progress with system stability.   We are a small engineering team. Every engineer has access to every part of the code base, and so one engineer can build and deploy an end-to-end feature without dependency on anyone else. In practice and over time, individual engineers become experts in certain aspects of the product. For example, one engineer, Sarah Gould, owns the set of design decisions for the mobile app UI and she is also responsible for executing the changes to that UI. The overall product plans for the next year are allocated to different members of the engineering team. Sarah has her UI feature roadmap for the year and knows the overall rough priorities. She figures out how to balance bug fixes, incremental changes, and new feature development within her area. Each engineer typically has a concrete schedule for a month, a rough schedule for the next three months, and an unprioritized list of everything else beyond that.  We deploy a new version of the AppSheet platform every working day. Because we deploy every day, the incremental change between versions is small. This promotes stability and it also allows us to deliver new features rapidly because features are not queued up waiting for a "release". When there are changes made to existing features, they are typically deployed using a gradual "rollout" process that allows us to ensure greater stability across our customer base.  Platform themes for 2018 So finally after all that preamble, here are the plans for 2018. If your favorite feature request doesn't fit in one of these themes, that's ok—our planning is continuous and evolving, so just let us know what you think will really help you get the most out of AppSheet. 1. Basics Further integrations—more data connectors, more workflow integrations System stability—keep up our pace of change without breaking customers, more automated tests, rewrite of app storage layer on the device Better performance—optimizations on our backend and in the app, faster background sync 2. App model enhancements Richer apps—richer UI (more forms options, calendars, structured search), more functions in expressions, richer deep links, more app customization and automation within the app Modular design—ability to create, share, and re-use app “modules” Security—limiting scope during signin, more auth providers (like Facebook) Device integration—expose hardware capabilities (Bluetooth, sensors) 3. Platform enhancements Intelligent feedback—understand the app creator’s intent, provide guidance on UI design, performance improvement, user analytics, etc Enterprise-grade—policies, domain and data sources inherited from root account, centralized billing, deeper integration with Active Directory and Google Domains, encrypted storage on device 4. Collaboration and Context More and better samples and videos for app creators Dynamic in-product tutorials to guide app creation Team collaboration features and user feedback to app creators 5. Moonshot: Natural Language For users in the app: search via natural language, chatbot apps V2 For app creators: high-level app descriptions in natural-language So when do we get started? As you can see, there's a lot that we plan to deliver. Keep an eye out for features that roll out with our daily deployments. We'd love to hear your feedback. I hope each of you finds a couple of things in there that are exciting and also useful for your apps. 

Need an App Maker? 3 Questions You Should Ask

  If you want to know how to make an app, there are three important questions to ask: What kind of app do you want to make? What are your technical skills? How much time and money do you want to invest? Once you have a rough sense of the answers to these questions (this should take about 5 minutes), you can choose an App Maker (an online platform that you use to make an app) and proceed. What kind of app do you want to make? This is the most important question, so we’ll break it up into three sub-questions. Q1: Is your app meant to be a large-scale consumer app (like a game or a shopping app) or is it meant to be used for work (in your business or for your team)? If you want to build a consumer app, then You need to be a software developer or hire software developers You will use a code-centric app development platform like XCode, Android Studio or Xamarin Your costs (time and money) will be high—probably $100,000 or more If, instead, you want to make an app for your work or team, read on. Q2: Who do you expect will use the app and why? It is always good to know who your initial users will be. The more specific the users and the use case, the better. Here are examples of good answers: The app users will be members of my sales team in the field who will use the app to capture new sales leads. The app users will be drivers of our delivery trucks who will use the app to record daily vehicle inspections A bad answer would be: My users are anyone in the world and they will use the app to communicate better with each other Q3: Can you describe what the initial version of the app should do? This is also a pretty open-ended question. If you haven’t already, you should definitely think about the requirements at a very high-level. Should it run on iOS as well as Android? Should it also run in a web browser? What data does the app use (eg: your existing customer data) ? Should the app be able to work offline? Does it need to show data or also capture new data? For now, let’s assume you need your app to run on a variety of mobile devices as well as web browsers, utilize some existing data in spreadsheets or databases, work in occasionally offline environments, and both show and capture new data.  What are your technical skills? Are you:  A programmer (you write software for a living)?  A knowledge worker (you use computer technology regularly in your job)?  A web and smartphone user (you use spreadsheets, forms, and apps etc)? If you answered yes to 1, 2, or 3, you could use a “no-code” app maker platform. The term “no-code” indicates that you do not need programming skills. Even if you do have programming skills, a “no-code” platform can make you much more productive. To learn more about this option, read on. If you answered yes to 1, you could write the app yourself. An app is just a program. It is tougher to write a mobile app than a regular web app because you have to handle offline behavior and the differences between iOS and Android. If you haven’t built a mobile app before, it is a learning experience and can be rewarding even just for the learning. There are a variety of platforms to consider. For example, you might want to think about writing a “native” app (an app specifically written to run on mobile devices): XCode is the programming environment for native iOS apps. Apple advocates that all new apps be written in the Swift programming language. Android Studio is the standard programming environment for native Android apps (sometimes called an ‘apk’). If  you chose this option, your app will be written in the Java programming language. It can be challenging to ensure that the app works the same on both Android and iOS if the code has to be written twice. Some solutions you might want to try: Use a programming environment like Xamarin. You write the code once and it translates the code to iOS and Android. The downside is that Xamarin doesn’t have all the features that each platform natively provides. Make a HTML5 mobile web app. This is really just a web app that runs in a web browser on the mobile device. It has the ease of development of a web app (if you are familiar with how to build a web app). However, it has all the limitations of a web app and in particular, will not work well offline. Make a “hybrid” app. This is a simple native app that hosts a web browser. Some part of your app is written with native code and some of it (usually, most of it) is written with HTML5. The advantage of a hybrid app is that you might also be able to get the same app to run in a regular web browser without much effort. A popular platform for hybrid apps is PhoneGap which is based on the Apache Cordova technology. Or use a “low-code” app builder. There are many such platforms that have emerged recently to make it easier to develop an app. The term “low-code” implies that these platforms provide some of the common code modules automatically so that what you need to do is to only write the remaining custom code components. To summarize: If you are a programmer, the good news is that you have many choices. However, many of these options are potentially expensive in terms of time and effort. If you are not a programmer, the good news is that you can choose a no-code app maker and be on your way to building your first app within an hour. However, you will be limited to the feature set provided by the no-code app maker you choose. How much time and money do you want to invest? Of course, this question has an entire spectrum of possible answers, but here are three main options to consider: Option 1: I want an app that is made in minutes and that is free. Option 2: I’m happy to put in a few hours to learn and get started, but need my app done in a few weeks. I do not have much budget to spend and I’d really like to at least start for free. Option 3: I need this done within a year. The project and a significant budget has been approved by our IT director. If you intend to write code or hire developers to write code, you fall into option 3 as options 1 and 2 are not really viable. But if you select options 1 or 2,  you should probably be considering a no-code or low-code app maker. Please note that if you selected option 1, we sympathize :]. Realistically, while it is possible to make an app in minutes, it is likely that it will take more time for you to refine it into a useful app. In practice, option 1 is the same as option 2.  We’ve pulled together a number of resources that will help you make your first app, regardless of the app making platform you choose (we like to think that our platform is the best but leave the final decision up to you). If you are a new app creator about to embark on your first custom app, this page is for you!  

How to Make an App—Things to Do in the First 7 Days

  Most teams in most industries will get more productive with custom mobile apps. Construction, transportation, utilities, oil and gas, agriculture, manufacturing, shipping ... the list is long. If you work in one of these industries and think a mobile app would help your team, this article is for you. It is a step-by-step planner on how to make an app and implement it for your business use case. The article will not advise you to hire software developers. In fact, absolutely not. The article tells you how to create your own app yourself or with the help of your own team. You need no knowledge of software development or programming. Instead, you will use a no code app platform called AppSheet that is explicitly designed for business professionals like you. In general, the concepts in this article apply to other no code platforms as well. A note of caution: every no code platform will claim you can create apps in seconds. So does AppSheet. That is true in a literal sense but it is also not true in a practical sense. You will have an app working in seconds or minutes. However, to build a good app, the one you want with the features you want, it will take some investment of time. I believe a week is sufficient, investing a couple of hours a day. Hence, the "7-day planner"! Before you start: Select an app platform I assume you are not a software developer. Even if you are, there are few who know and relish the complexities of programming mobile apps. Instead, you may have heard of two new kinds of rapid application development platforms: "Low-code": these platforms make it easier for a software developer to build an app. Instead of starting from scratch, they provide a framework into which the developer writes code modules. In a sense, every software platform can claim to be low-code. Even IBM claims to have a low-code platform! This is primarily an option for software developers to consider. "No-code": these platforms are fundamentally new. Rich and complex apps can be built without writing _any_ code. You do not need to have ever written a program in your life. For most people, this is the way to go. I recommend using AppSheet—it is one of the most powerful no-code platforms available and you can build and test your apps for free. A canonical example: Recently, a customer posted this question on the AppSheet community site:    "I have a construction business. I am building a set of apps to have full control of what is going on on our job sites. One part I need to follow up is a daily production for every employee. I built a spreadsheet where I have entered all data previously referring to a specific task, in this case it is water coating. Now I have populated this sheet with existing data, and my goal is to create an app that the supervisor at the job site is able to "check off" once verified that the task is complete. This will then add up the coating applied every day by each employee and I will track how much is applied in every job site." We'll use this as the running example through this article. You probably have one or more apps that you want to build, each with different requirements. You'll find it easy to map the ideas presented here to your needs.  Things to do: the 7-day plan Day 1: Create an AppSheet account. Understand the concepts.  Day 2: Build the first version of your app Day 3: Show/send your app to some actual users in your team Day 4: Add some richer features— photos, GPS, charts, maps, etc Day 5: Demonstrate your app to your boss Day 6: Enjoy your weekend and your promotion! Day 7: Can't wait to get back to improving your app. Day 1: Learn the ropes Go to the AppSheet site and create an account. Most users already have a Google account, so it is easiest to sign into AppSheet with your existing Google account. In this article, we'll assume you do this, although a variety of other options are also available. How to make your own app? You need to understand the concepts. Your app is based on data that you define. In our running example, the app has four sets of data: Customers, Employees, Building Tasks, and Daily Jobs. Once you define this data by putting each set of data into a Google spreadsheet with columns (structure) and rows (content), the platform automatically creates an app from this data. The structure of the data guides the user interface of the app. The app shows the data content and optionally lets the users modify the content. From this starting point (created in seconds!), you can refine the app to suit your needs. You should read more about app design here. And how is the app going to run? You need to understand how the AppSheet platform works. Sometimes a picture is worth a thousand words. You can learn more about it here. The main thing to understand is that your app isn't going to be generated as source code or an executable. Rather, there is already an AppSheet mobile app ready to install in the iOS or Google Play app stores. The app you define will simply be hosted within it. It will fetch the data from your cloud-based spreadsheets and make it available on your mobile device, then use your app definition to show the data to the app users, and synchronize any data changes all the way back to your spreadsheets.  You should check out some of the sample apps here. Make a copy of one or two and modify it to get the hang of building your own apps. Also be sure to install and play with the AppSheet app on your phone. This is a fun day! Day 2: It begins Now things get serious. You need to get a first version of your app running today. It really only takes three steps, but you will repeat the last step iteratively to gradually improve and refine your app. Define your data: create a cloud-based spreadsheet for each of the data entities in your app. A Google Sheet is simple to create and works great with AppSheet. If you are building our running example, create four spreadsheets—Customers, Employees, Buildings, and Jobs. Fill them with some regular sample data. Put in a clear header row for each sheet. For example, the Customers sheet may have Id, Name, Address, and Email as columns. Create an app: on AppSheet's web site, click on 'Make a New App'. Follow the instructions, and when prompted, choose one of the spreadsheets you have built (eg: Customers). The system builds an app automatically for you (yes, in seconds!) and runs the working app in an app emulator right there on the browser page. Now add the other three sheets as well. In your app, each of these is going to be called a Table. Your app's data model is a collection of Tables. The app has some default Views defined to show the data in these tables. Refine the app definition: now you can make as many changes as you want. AppSheet has a very rich set of capabilities. Don't try them all. Here are a few simple things to try first: Add or modify the UX views to see how you can control the presentation of data Use the app emulator to see how the app can be used to capture new data or edit existing data. Modify the behavior by changing which columns are shown and which are hidden. You will likely need to go back and add more columns to the spreadsheets. Each time you do, make sure to go the column structure definition in your AppSheet app editor and "Regenerate" the structure. It is important that your app and the underlying spreadsheets are consistent. Try adding a simple data formatting rule using a formula. The expression language used for formulas is similar to the language used in Excel/spreadsheet formulas. Most of the powerful and dynamic features of richer apps are based on the use of such expressions. Don't forget to try your app on a mobile device as well. You are on a steep learning curve. You will have many questions. Join the AppSheet user forum so that you can ask and get help. But the good news is that you have your first working app. Though it doesn't yet do exactly what you want it to do, you are officially an app maker. A succesful day! Day 3: Time to share It is going to feel odd because you just got started, but by the end of this day, you're going to share the app with some actual users. Let's assume you are building the app for members of your team. Those are the users to target. Find more than one and less than five target users who you will invite to try using your app. The first thing to do is to identify what you think are the most important three features you want in your app and write them down. Only three? But you had twenty features planned. It's so tough but you whittle them down to three top features. Then focus on just the first one on the list. Yes, I know that seems like an unfair trick but believe me it will help you. You're probably sure that your users will hate your app unless it has all twenty features. I'm here to tell you you may be right (eventually) but you're wrong now. It doesn't matter at the start. I've seen tens of thousands of customers make their apps on AppSheet. You have to start by getting one feature into the app and getting that app into the hands of your target users. In the case of our running example, the important feature is to mark a Task as complete and record the amount of coating applied.  For this of course, the Tasks have to be shown, a specific Task must be selectable, it should be possible to update it to mark it complete, and the coating amounts from all the Daily Jobs for that task should be summed up. Fortunately, almost all of this is already automatically generated in your app. You will have to write a formula to sum up the coating amounts and add that into a "virtual" column to keep track of it with every Task. Most likely you will try out a few other features because you want to impress your colleagues. Then you go to the Users tab in the app editor, enter the email addresses of your test users (not your manager/boss yet!— find actual people who would use the app eventually), take a deep breath, and hit the Share button. This is a busy day! Day 4: A shot of adrenalin Wow! Your team didn't hate it. Instead, they look at you with awe (or at least grudging respect) because you did something amazing. You built a custom app that could actually save them time.  Of course, instead of thanking you, they will most likely give you many many suggestions of things to do to improve the app. Your list of twenty features just grew to forty. This is terrific news and in fact exactly why you shared the app with them in the first place. They are telling you what matters and what doesn't.  And what if they seem most unenthused. It isn't because the app is bad or your work is bad. It just means the feature you picked isn't the one that matters. Just go back and pick the next one on your list to try instead.  Either way, you now have a lot more information (real and validated) than you did just two days ago. You've got work to do. Take that input, add or change the appropriate features and utilize some of the features AppSheet provides. Here are some ideas for our running example: Color active tasks differently from completed tasks. Use a single action button to indicate task completion instead of opening a form. Set up a workflow rule to send an email to the manager when a task is completed. Show a chart of the total coating applied per job A crazy busy day! Day 5: Crunch time Yes, today is the day you show the app to your manager. Obviously, your job title is not "App Maker". This was likely a self-driven initiative, so you're likely to be nervous. What if the manager doesn't really think this is worth it? You'd better prepare for this. Three simple steps will make this go better: Make sure the app works! You have to demonstrate it. Don't be making changes till the last minute—it is the sure-fire way to break something just before the meeting. Practice a simple demo walk-through that shows the main feature(s) of the app. If possible, show it running directly on your phone. Read about platform pricing here so you can answer the obvious questions about how much (little, actually!) this is going to cost. And for fun, make sure you also compare this with the cost of hiring developers to build mobile apps. Instead of spending an average of > $100,000 to make an app, you just did it yourself. Make sure to share the feedback you just got from your test users. That is often the most compelling information for a manager to realize you are onto something that will benefit the entire team.  I do not want to claim that this conversation always goes well. There are all kinds of organizations and some are naturally more willing to embrace change and innovation. There will certainly be managers who don't think there is value in innovating with a mobile app. You will need to make the case for it, and it may not be easy. However, it may help to be aware that there are tens of thousands of people like you worldwide who are following the same path and making their own apps. There is a new wave of "citizen developers" and this is becoming one of the newest trends in business. So you are not alone. Usually, your enthusiasm and creativity wins out, and your organization sees the merit of your work and initiative. And even when that happens, it is still a stressful day! Day 6 and 7: Rest, recuperate, and ... Yes, it's the weekend. Yes, your manager and your team really liked your work so you feel really good. And yes, you've got a game to watch on TV and are looking forward to family time. But I'm sorry to say this—the reality is that you won't really get to enjoy both weekend days!. By the morning of day 7, your mind will be thinking of the next few features to add to your app, and by the afternoon, you will have opened your browser and started to work again. You have so much more to learn about the AppSheet platform, and so many app ideas to pursue.  Happy app making!

Build or Buy Mobile Apps: Focus on the Platform, NOT the App

  A recent ComputerWorld article shed some light on Santa Clara County CIO Ann Dunkin’s conundrum: Should Santa Clara build or buy mobile apps? I suspect this is a question many city CIOs are asking themselves as they try to figure out how to offer their city residents a mobile-friendly, one-stop shopping experience that is platform-agnostic. Based on past experience, Dunkin imposed the following criteria on app development projects: First, consider the applications that the city currently has and explore ways to leverage them to address the need. Second, look to SaaS providers as possible solution candidates. Finally, if the first two options are exhausted, consider building the app in-house. I understand Dunkin’s reasoning: why build your own if there are commercial apps available? In this respect, it comes down to core competencies. However, I suspect that Dunkin and the IT organization find themselves having to build custom apps often to fill gaps between solutions as well as offer their citizens apps that address specific needs where there is no viable off-the-shelf solution. I also suspect that like most IT organizations, the city of Santa Clara is facing an ever-growing backlog of app requests comprised of new apps or extensions to existing apps. This is my question to all the CIOs trying to meet the needs of their citizens or business users: Why not standardize custom app building on one development platform to meet your needs? No-code and low-code app development platforms are far more cost-effective in terms of maintenance and support than their traditional counterparts. For example, no-code platforms like AppSheet are specifically designed to take the complexity out of app development. Our goal is to enable any business user to create the apps they need to automate a business process, address a specific business problem, or simply fill a digital gap. Platforms like ours revolutionize the app development process by putting app creation in the hands of business users, those folks who know what they want their app to do, what features it should have, what content should be shown on each screen, what information should be collected, etc. I can’t speak for other no-code platform providers but I can say that a number of cities use our platform for mobile app creation for the very reasons I outlined above. But don’t get me wrong: in the no-code (or even low-code) app development platform world, IT still plays a central role in terms of governance, security, privacy, and scalability. These are IT’s core competencies and if the platforms you’re looking at don’t fully address these issues, remove them from your list. When deciding whether you should build or buy custom apps, first consider the development platform. After all, it’s not about building the app, it’s about selecting the right platform. Once the platform is in place, build versus buy becomes an easy decision.

The Wand Chooses the Wizard: the AppSheet Customer Definition

This is part of the AppSheet Manifesto series about the beliefs and principles that form the basis of the AppSheet platform. The manifesto has three major customer-centric assertions: a) about the technology, b) about the product, and c) about the business. This article is about the second assertion—a tiny startup team starts from scratch and rapidly builds a broad app platform for tens of thousands of customers. We have done this by adopting a somewhat surprising principle. Our customers are our team. And here is what we mean by customers in the AppSheet dictionary. Background: product development methodology Before starting AppSheet, I spent more than 12 years at Microsoft in various engineering management roles. My co-founders also have significant experience at large software companies. As it turned out, much of what we learnt with that experience had to be un-learnt as we built AppSheet. Here's why. There are two broad models for product development. One model says—we know the market, we know who the customers are, we know the requirements, we can build a better solution than the current state of the art, and we'll convince customers to try it and then buy it. This is the traditional model. The other model says—we don't really the know the market, the customers or their requirements. We just have a vague idea. We cannot build a better solution when we do not know the problem accurately. All we can build is the raw outline of a solution. We have to put it in front of customers, learn from them, and iterate fast. This is generally called the "lean" model of product development. Our philosophy took lean development one step further. We believed we could not really convince anyone to try what we built. Customers are smart, busy, and constantly fending off dozens of vendors hawking their products. Our potential customers have to actually want to try it themselves. We cannot find customers: they have to choose us! "The wand chooses the wizard, Mr. Potter"  When a new person joins our company, I usually ask them a month or two into their tenure to try to personally acquire one customer. Convince one human being to use our product! It turns out to be difficult to do and particularly so in the early days of the product. So why does a customer adopt an early and primitive product? It isn't because it solves a short-term problem. It is because it shows the promise and the potential to be molded into something that can really deliver value. The wand chooses the wizard—the customer chooses to invest their time, energy, enthusiasm and commitment in the product. The customer who does this is an innovator in their environment, a risk-taker, an idealist. The customer is willing to pursue an idea that may have a low probability of success. The customer has "magic" and our product is only a vehicle for that magic to express itself. So the crucial step in product development is to put ourselves in the neighborhood of these magic innovative customers and hope they will choose us. That's what we did by placing an add-on into the Google Sheets add-on store. The add-on simply said "Build mobile apps from your spreadsheet". And amazingly, we started to see a small but steady stream of customers trying our early product. Now the next question is—what do we do with these customers when our early product is missing many important features, inefficient, and generally embarassing? The answer: listen to every word they say, and find ways to reach out to them to hear what they have to say. Because what they say sets the roadmap for the product. Customers as our product managers A product manager decides what features go into a product. By AppSheet definition, customers are our product managers. One of the first things we did was set up an online customer community. It started with three members, and just this week, it crossed 8,000 members! On a daily basis, we receive almost 100 messages and responses from customers.  Sometimes people asks for specific features that we don't have, for example, "Can I send an email when an order is captured via my app?" And we scramble to add a workflow rule feature. But far more often, it requires a back-and-forth to understand the real issue. Sometimes it takes more than one customer asking about something for us to realize how important it is. And conversely, if people don't ask for it, it probably isn't important. This requires a commitment to read and to answer every customer message. In the early days, we would even proactively reach out to specific customers (e.g., "Hey, our logs show that your app is running really slowly. Can we do something about improving it?"). For a while, we ran a "Feature of the Week" poll. We asked our customers to vote for one of three features, and whichever was the winner by Friday, we'd work through the weekend to have it ready to deploy on Monday. An amazing and exciting time!  As the product has grown and the customer volume has grown, it has become a challenge to scale this level of customer engagement. We requested some of the leading community members to act as community moderators. This is actually one of the best attributes of our community—the community helps each other, the moderators are experts and when they raise issues directly with us, we know they carry the "wisdom of the crowd". Customers as our engineers Customers cannot design or architect our core product. That is our responsibility. All the same, there are many things we do that involve our customers in engineering activities. First and foremost, our software engineers directly handle product support and customer engagement. There is no buffer between customers and engineers. The more the engineers engage with the customers, the more they truly understand the product that should be built. Our customers are also our product testers. We intentionally release new features when they are in an early beta state. With tens of thousands of customers with a huge variety of usage scenarios, we know we are not equipped to flush out all the use cases for a new feature. However, our customers are and they do. Our customers write app samples that they share with others. And while we haven't done this yet, our roadmap includes the ability for our customers to write app modules that can be re-used and shared by other users.  Customers as our marketers Marketing a product is a simple task to define—make potential customers aware that the product exists and can solve a problem for them. Most companies spend a lot of money on marketing. As a startup company, we simply didn't have the money to spend on marketing. That helped us discover that our customers are actually our most effective marketers. Our initial set of customers found AppSheet via add-ons in the Google Docs ecosystem. We started to write content about AppSheet but found that nobody really wanted to read an article from yet another company talking about itself. On the other hand, we started writing stories about our customers and found these were way more compelling. After a year in business, we started to observe an increase in traffic from people who came directly to AppSheet. We also found an increase in traffic from Google Search and the dominant search keyword was "AppSheet"! Which means all these new customers had heard about AppSheet from someone else. Almost always, from a happy existing customer.  Customers as our sales reps It is one thing for a customer to try building an app with AppSheet. It is a completely different thing for a company to commit to moving its business process onto the app and paying for it. That requires someone to sell the idea to a decision maker and for that decision maker to commit. We didn't have a sales team. So how did we end up with a few thousand paying accounts? Very simply, it is because our app creators also became our sales team. Here is why we we say "customers are our sales reps" by AppSheet customer definition. Our app creators are innovators looking to change the world they work in. Once AppSheet allows them to convert their ideas into something practical, they "sell" and convince their organization to buy into their ideas. Something else happened that we didn't anticipate—more than a hundred of our customers have become solution partners. They use AppSheet to build apps for other people. Some of them quit their fulltime jobs to pursue this new career. It is inspiring and amazing to see how this has evolved. Our contract with our customers We will try to respond to every communication promptly. If you take the time to write, we should respond. The people who respond will have the knowledge and the power to make decisions. If we intend to support a feature, we will tell you so. If we don't, we'll explain why. If it falls in-between, we'll try to be clear on that too. We will take your collective guidance as we move the product forward. Yes, we're going to screw up occasionally—when we do, we will apologize. We're in this together. As CEO, the most important part of my job is to listen to our customers, to respond honestly, and to take their collective guidance. Every customer has always had direct access to me just like every member of the AppSheet team in Seattle. My email address is and I value every comment you send my way. The AppSheet Manifesto Part 1: How AppSheet Was Founded The AppSheet Manifesto Part 2: No-Code is "Know"-Code   In Founder's Notes-The AppSheet Manifesto part 4, we'll talk about design of the business aspects of AppSheet, how we think of partnerships, pricing, small business versus enterprise, and the role of customers in guiding this process.   Citizen Developers are Workplace Innovators. They build custom apps to improve and optimize work processes in their organizations, introducing innovative ways to "get work done." As citizen development becomes the new normal, it promotes innovation, agility, and flexibility throughout an organization. To learn more about AppSheet and citizen developers, check out the following page: