Category Archives: Kerika

Posts about Kerika, the company and its people

Our latest version, and then some!

Kerika, Technology, Usability,

In the immortal words of Jim Anchower: “Hola, amigos. I know it’s been a long time since I rapped at ya.”

Our apologies for not posting blog entries for a while, but we have the usual excuse for that, and this time it’s true: “We’ve been incredibly busy building great software!” It’s going to be hard to summarize all the work that we have done since June, but let’s give it a shot:

  1. We have curved lines now. And not just any old curved lines, but the most flexible and easy to use drawing program that you are likely to encounter anywhere. You can take a line and bend it in as many ways as you like, and – this is the kicker – straighten it out as easily as you bent it in the first place. There’s a quick demo video on YouTube that you should check out.
  2. We have greatly improved the text blocks feature of Kerika. The toolbar looks better on all browsers now (Safari and Chrome used to make it look all scrunched up before), and we have added some cool features like using it to add an image to your Kerika page that’s a link to another website. (So you could, for example, add a logo for a company to your Kerika page and have that be a link to your company’s website.) Check out the nifty tutorial on YouTube on text blocks.
  3. You can set your styling preferences: colors, fonts, lines, etc. Previously, all the drawing you did on your Kerika pages was with just one set of colors, fonts, etc., but now you can set your own styling preferences, with a new button, and also adjust the appearance of individual items.
  4. We have improved the whole Invitations & Requests process. Now, when you invite people to join your projects, the emails that get sent out are much better looking and much more helpful, and the same goes for requests that come to you from people who want to join your projects, or change their roles in your projects. Check out this quick tutorial on how invitations and requests work.
  5. We have made it easier for you to personalize your Account. You can add a picture and your own company logo, which means that when you use Kerika your users see your logo, not ours! Check out this quick tutorial on how to personalize your Account.
  6. We have hugely increased the kinds of third-party content you can embed on your Kerika pages. The list is so long, we really should put that in a separate blog post. We have gone way beyond YouTube videos now; we are talking about all the major video sites (Vimeo, etc.), Hulu, Google Maps, Scribd and Slideshare… The mind boggles.
  7. Full screen view of projects. There’s a little button now, at the top-right corner of the Kerika canvas: click on it and you will go into full-screen mode, where the canvas takes up all the space and all the toolbars disappear. This makes it easy to surf pages that contain lots of content, or work more easily with your Google Docs.
  8. Full support for Internet Explorer 9 (IE9). Not as easy as you might think, given that Microsoft has historically gone their own way, but we have sweated the details and now Kerika works great with IE9. As Microsoft continues to converge around common standards, this should get easier for us over time.
  9. Full support for all desktop platforms. OK, so this isn’t really a new feature, but since we are bragging we might as well emphasize that Kerika works, and is tested, to work identically on Safari, Chrome and Firefox on Windows 7, Mac OSX and Linux.
  10. Literally hundreds of usability improvements. Yeah, okay, we should have gotten it all right in the first place, but our focus over the past few months has been very much on working directly with our early adopters, observing them use the product, and noting all the tiny friction points that we could improve upon. We are not saying that we have all the friction removed, we are just bragging about the hundreds of tweaks we have made in the past 3 months.

Since June, we have had two major releases: one at the end of July that had nearly 150 bug fixes and usability improvements, and one this week, with over 120 bug fixes and usability improvements.

The product is now in great shape from an infrastructure perspective: the core software has been well debugged and is now very robust. Performance is great: you should get sub-second responsiveness when working in an environment with decent broadband wireless, where you see updates to your project pages in less than one second after a team member makes a change. (We test this with users in Seattle and India working simultaneously on the same project.)

Having this robust infrastructure that’s been well debugged and tuned makes it easy for us to add new features. In the coming weeks, look for more social media hooks, a revamped website, an extensive collection of public projects (that you can use as templates for your own work), and more. Much more. After all, if “less is more”, just think how much more “more” could be ;-)

Some thoughts on software patents

Intellectual Property, Kerika, Technology

A very big day for us at Kerika: after more than six years of perseverance, we finally got our first patent issued today: United States Patent No. 7,958,080. (Yeah, that’s certainly a big number: a lot of people were granted patents before us!)

There is a lot of debate in our profession about software patents: strong opinions have been voiced in favor of granting software patents, and equally vociferous views have been aired in opposition to the entire concept. What’s discussed much less frequently is how long it can take to get a software patent, or expensive and arduous the process can be.

Our original provisional application was made on October 29, 2004; this was followed up with a final application, and then dead silence for a couple of years. When the Patent Office finally examined the patent application, there was a multi-year exchange of correspondence with the Examiner, with the Examiner making various arguments in opposition to granting a patent, and our lawyers making counter-arguments in favor of Kerika being granted a patent.

All this back-and-forth is quite normal, by the way, and works as designed: it’s the Patent Examiner’s job to not grant patents without challenging their claims, and it’s the applicant’s responsibility to offer increasingly stronger arguments in favor of being granted a patent. What is finally granted is usually a subset of the claims that were made in the initial application. It’s very rare for all of the initial claims to be granted.

Software patents are harder to get, and take much longer to be granted, than hardware patents, probably because it is easy to compare one tangible object with another and determine whether one is materially different than the second tangible object.

Software is harder because it is intangible: you have to describe an intangible item, using the jargon that’s peculiar to patent applications, in way that clearly distinguishes it from another intangible item.

The net result is that a software patent can take many more years to be granted, in comparison to a hardware patent. One of the problems with the process taking so long is that, by the time the Patent Examiner gets around to examining your application, the technology may have become so prevalent in other, competing products that it no longer appears to be as innovative as it was when the application was first made.

The entire process is also very expensive, particularly if you are a solo inventor or small startup (as we are): the Patent Office has been hiking its fees over the years, with the stated intention of hiring up more examiners, and thereby speeding up the process, but clearly they are having a hard time keeping up with the flood of applications because it seems like the delays are getting worse, not better.

Regardless of whether you are pro or con software patents, we would argue that both sides of the argument would be served better if the process of examining, granting or rejecting a patent were shortened very considerably. If a patent could be examined and acted upon within 2-3 months, it would entirely change the debate as to whether software patents are good or bad for innovation.

Meanwhile, back at the ranch… we have other patent claims in the works, which we hope will take less time to work its way through the Patent Office now that our first patent has been granted!

Out of the billowing smoke and dust of tweets and trivia emerges our first patent

Intellectual Property, Kerika, Technology

“The literati sent out their minions to do their bidding. Washington cannot tolerate threats from outsiders who might disrupt their comfortable world. The firefight started when the cowardly sensed weakness. They fired timidly at first, then the sheep not wanting to be dropped from the establishment’s cocktail party invite list unloaded their entire clip, firing without taking aim their distortions and falsehoods. Now they are left exposed by their bylines and handles. But surely they had killed him off. This is the way it always worked. A lesser person could not have survived the first few minutes of the onslaught. But out of the billowing smoke and dust of tweets and trivia emerged U.S. Patent No. 7,958,080 to be issued on June 7, 2011. Once again ready to lead those who won’t be intimated by the political elite and are ready to take on the challenges America faces.”

Out of the billowing smoke and dust of tweets emerges our first patent
Out of the billowing smoke and dust of tweets emerges our first patent

Our first patent! We are hoping the coming apocalypse doesn’t cause any more delays at the Patent Office; we have been waiting a long time for this patent to get issued, and there are more in the pipeline!

Up next: a replacement for the Google Docs Gadget

Kerika, Technology, Usability

The current version of Kerika uses an embedded Google Docs Gadget, that’s part of the Sidebar within the application. There’s no polite way to describe this software, which comes in four different flavors from the mighty Google itself; let’s just say that the technical term for it is “p.o.s. software”.

A Google Docs Gadget is supposed to be something that you can easily embed within a website or application: it supposed to provide easy, direct access to your Google Docs from within your site or Web App. There are at least four official Google Docs Gadgets out there:

  • There’s this one from “Claudia C. and Ted C.“, both employees at Google – as you can easily see by viewing the XML code for this Gadget. It doesn’t work, which probably explains why Claudia and Ted are coy about revealing their last names. And when we say it doesn’t work, we don’t mean that it has some subtle bugs that are unlikely to surface for most users: just visit this Gadget, at Google’s own official website, and try setting the number of documents to show in the list. It doesn’t work.
  • Here’s another one: presumably a later one than the first, since it’s authorship is attributed to “Claudia C. and Ted C. Modified by Gordon Bunker”. We don’t know who Mr. Bunker is, but he couldn’t get Claudia and Ted’s Gadget to work properly either.
  • Here’s a third one: also the work of Claudia C and Ted C. This one is hilariously broken: just visit the link that says “Add to your home page” and you see the helpful message “Error parsing module spec: Not a properly formatted file missing xml header”. So, here we have an example of two Google employees, hosting an official Google Gadget, on Google’s own website, that is completely broken…
  • Finally, we have this one, attributed to “Claudia C., Ted C., and Sam B.”. Sam, like Claudia and Ted, found it wiser not to disclose his last name given he somehow managed to reduce the utility of the original Gadget.

So, there you have it: four different, official versions of the embeddable Google Docs Gadget, none of which work… The situation became untenable for us because with the latest version of Google’s Chrome browser, the drag-and-drop function stopped working altogether. No small irony here, that Google’s own browser doesn’t work with their own Gadgets, when Firefox’s drag-and-drop continues to work.

We can’t fix these Gadgets because they were built by Google employees; instead, we are building our own replacement for this Gadget which we expect to release this weekend. It’s simple, functional and reliable. It will let you perform a search across all your Google Docs, and drag-and-drop results from this search straight onto your Kerika pages. And, it will work on all browsers.

First, we kill all the managers. (Or, maybe not.)

Kerika

In earlier posts we described our decision to chose Amazon’s EC2 over Google App Engine in recent days, and as part of the business perspective we noted that:

Amazon is accessible: both Amazon and Google have engineering centers in our neighborhood, and Amazon’s is, of course, the much larger presence, but the real issue was which company was more accessible? Amazon does a lot of outreach to the startup community in the Seattle area – Jeff Barr is everywhere! – whereas Google is a lot more aloof. It’s much easier to find an engineer or product manager at Amazon who will talk to you, and that really makes a difference for a startup. Real people matter.

Events in the past week have reassured us that we made the right choice. The very end of that post on choosing EC2 included a passing grumble about some long-standing problems with Amazon’s Elastic Load Balancer.

What happened following that blog post was a pleasant surprise: an old colleague saw the post on LinkedIn and forwarded it to someone at Amazon, who promptly contacted Jeff Barr, the peripatetic and indefatigable evangelist for Amazon Web Services.

And within just one day after our griping, Jeff asked for a meeting with us to see how Amazon could make things better for us. This level of responsiveness was, frankly, astonishing when one considers the size of Kerika (rather tiny) and the size of Amazon (rather Amazonian).

We met Jeff today, and are happy to report that this ELB issue will soon go away for us and everyone else. But that was a minor aspect of the meeting: much of our discussion was a wide-ranging conversation about Kerika, collaboration platforms and the many uses for cloud computing in different market segments.

And the best part was finding out that Jeff had taken the trouble, earlier in the day, to try out Kerika for himself.

Returning from the meeting, we couldn’t help but reflect upon cultures of the two companies that we are relying upon for our business model: Amazon and Google. Amazon is providing the cloud computing infrastructure, and Google is providing the OpenID authentication and, more importantly, the Google Docs suite that is integral to the Kerika product offering. Both sets of technologies are essential to Kerika’s success.

But the cultures of these two companies are clearly different: Amazon relies on both technology and people, whereas Google, it would appear, is purely an online presence. (To be fair, we must note that while both companies have engineering centers in the Seattle area, Amazon’s footprint is many times larger than Google’s.)

But, still: who could we have tried to reach at Google? Who is the public face of Google’s App Engine? Or, of Google Docs, for that matter? There are two substantial Google engineering centers nearby, but Google the company remains a cloud of distributed intelligence – much their servers – accessible only via HTTP.

A recent article at All Things D speculates that Larry Page may eliminate Google’s managers in large amounts, in order to free the animal spirits of the engineers, and a similar article on TechCrunch notes that “Page famously has a low opinion of managers, especially product managers who try to tell engineers what to do.”

There can be no gainsaying Google’s engineering talents, or its remarkable achievements, but will Google 3.0 be an organization that has even less human contact with its customers and partners?

Why we chose Amazon’s EC2 over Google’s App Engine: the CTO’s Perspective

Kerika, Technology

A previous post discussed our decision to use Amazon’s EC2 service over Google’s App Engine and Microsoft’s Azure service primarily from a business perspective: the risks we weighed when we made our technology choices last August, and why the decision went in favor of EC2.

(We have also noted previously – lest anyone consider us uncritical fanboys! – that there are limitations with Amazon’s Web Services that have given us some heartburn.)

In today’s post, we present the CTO’s perspective: why EC2 was more attractive from a technology perspective:

The advantage of using Amazon’s EC2 over Google App Engine and Microsoft Azure is that for a highly interactive web applications such as Kerika, there needs to be multiple levels of caching of data.

Kerika maintains a cache within the browser so that it can avoid round trips to the server when the user moves objects around on the screen. Without that cache, the delays would be so long that users wouldn’t feel they were using a highly responsive desktop application – making it harder for us to .

There also needs to be a cache on the server side, and the most compelling reason for this is to reduce load on the database.

There are various ways to scale up a database, but none are as effective as simply minimizing the load on the database in the first place. A server-side cache is a simple way to do that. Because Kerika supports relationships between users, projects, idea pages, and so on, the server side cache has to maintain those relationships.

The Kerika server also must keep track of the state of the caches on its clients so that the it can maintain the clients in a current state, and thus avoid round trips to the server.

As a consequence of all this, Kerika uses servers with a large amount of RAM that needs to be quickly accessible for all of its users. Storing a large amount of data RAM is where EC2 becomes the only way to solve the problem. Because App Engine and Azure do not allow us to manage large amounts of RAM, they just weren’t good solutions for Kerika.

Another technical challenge is maintaining the long-lived browser connections that a Web application like Kerika depends upon. Google App Engine has the Channel API, but that doesn’t quite cut it for an application like Kerika.

Kerika needs to maintain several channels concurrently because users can be working with different combination of objects at the same time.

Kerika also makes use of broadcasts as a simple way to keep multiple users up to date. Because of EC2’s open architecture, we can use CometD as an off-the-shelf solution for client communication.

Finally, Google App Engine’s business model, which calls for charging two hours for each token doesn’t make economic sense in an environment where users are expected to navigate from page to page through the course of the day. EC2’s “pay-as-you-go” allows us to manage our traffic and keep operating costs down.

Choosing between Google’s App Engine and Amazon’s EC2

Kerika, Technology,

Back in the summer, when we were making our technology choices, we had to decide which company was going to provide our “cloud”. It really boiled down to a decision between Google’s App Engine and Amazon’s EC2. Microsoft’s Azure service was still relatively new, and in talking to one of their product evangelists we got the distinct impression that Microsoft was targeting Azure for their biggest customers. (That was nice of their product evangelist: not taking us down the garden path if there was a mismatch between our needs and Microsoft’s goals!)

Here’s why we chose EC2 over App Engine:

  • Amazon is accessible: both Amazon and Google have engineering centers in our neighborhood, and Amazon’s is, of course, the much larger presence, but the real issue was which company was more accessible? Amazon does a lot of outreach to the startup community in the Seattle area – Jeff Barr is everywhere! – whereas Google is a lot more aloof. It’s much easier to find an engineer or product manager at Amazon who will talk to you, and that really makes a difference for a startup. Real people matter.
  • There was negative buzz about App Engine, at least back in August. People in the startup community were talking about suffering outages, and not getting very good explanations about what had gone wrong. Google’s aloofness didn’t help: there wasn’t anyone reaching out to the community to explain what was happening and there was little acknowledgment of problems coming through on Google’s official channels.
  • To beta or not to beta? Google’s rather lavish use of the “beta” label (remember the many years that Gmail was in beta?), and their recent decision to pull the plug on Wave added to our nervousness. Were they serious about App Engine, or was this another science experiment?
  • An infinite loop of web pages: in the absence of any physical contact with Google, we tried to learn about their service through their web pages – well, duh, of course, dude! The problem was that much of the information is presented in a series of rather small pages, with links to more small pages. As an approach to information architecture – particularly one that’s biased towards being “discoverable” by a search engine – this makes a lot of sense, and the Kerika website takes as similar approach. The risk with this approach is that you can very easily find that you are following links that take you right back to where you started. (And our website runs the same risk; we look forward to your comments detailing our failings in this regard!)

While we were pondering this choice, Google came out with a rather interesting offer: unlimited free storage for a select handful of developers. (How select? Probably as select as one of Toyota’s Limited Edition cars, production of which is strictly limited to the number they can sell.) The offer was presented in the usual mysterious way: you went to an unadvertised website and made an application. Someone would let you know “soon” whether you would get past the velvet rope.

We thought we had a good chance of getting included in the program: after all, Kerika was designed to add value to Google Docs, and we were using a number of Google’s services, including their Open ID for registration. And, indeed, we were selected!

The only problem was that the reply came about 4 weeks later: an eon in startup time. By that time, we had already decided to go with EC2…

(Is EC2 perfect? No, not by a long shot, and we were particularly annoyed to find a rather fatal flaw – from our perspective – in the way their Elastic Load Balancer can be configured with canonical web addresses: a problem that’s been noted for 2 years already. Not cool to sit on a problem for 2 years, guys. Not cool at all.)

The development environment that’s worked for us

Kerika, Technology

In our last post, we referred to our “dogfooding” Kerika by using for our testing process. Here’s some more information about how we set up our software development environment…

Our Requirements:

  • We needed to support a distributed team, of course. And our distributed team had a variety of preferences when it came to operating systems: there were folks that liked using Windows, folks that had only Macs, folks that used only Linux, and folks that liked using Linux as virtual machines running inside Windows… Since we were were developing a Web application, it didn’t make sense – neither from a philosophical perspective nor from a business strategy perspective – to insist that everybody use the same operating system. If we were going to build for the browser, we should be able to use any operating system we preferred: our output was, after all, going to be Java, Javascript and SVG.
  • We needed to deploy our software “in the cloud”, and that meant making sure our software could run well in a Linux environment. Microsoft’s Azure service was still relatively new, and, in any case, our back-end developers were more comfortable with Java than ASP.Net, so that fixed Java on Linux as a back-end requirement.
  • Our software had to run in all browsers: that effectively meant “modern browsers”, that happy euphemism for browsers that would conform to HTML5 standards. When we started development, we were uncertain about how Internet Explorer 9, which is still in beta, would evolve, but we have been very pleasantly surprised by the evolution of that product. (And a discussion in December with Ziad Ismail, IE9’s Director of Product Management, has since further reinforced our belief that Microsoft is very serious about standards compliance in IE9.)
  • We decided early on to build our front-end in Javascript and SVG, rather than Flash. We know of very few applications, even today, that attempt to deliver the kind of user interface combined with real-time networking that Kerika does using Javascript, and it’s not that we like crazy challenges because we are crazy people –we just didn’t want to get caught in the crossfire between Apple and Adobe over Flash. Having to choose between Caradhras and the Mines of Moria, like Gandalf we choose to brave the Mines…

Our choices:

  • Amazon’s EC2 and RDS for creating test and production environments; A2 hosting for our development environment. The choice was between EC2 and Google App Engine, and we will talk more in a separate blog post about why we chose Amazon over Google.
  • Eclipse for the developer’s IDE: it was cross-platform, and since everyone wanted to stick with their favorite operating system, it was Eclipse that straddled them all.
  • Jetty for web server: the choice was between Apache and Jetty, and we went with Jetty. Why? Well, that’s a blog post in itself…
  • Git for source code control: we looked at Subversion, but Git is better suited for distributed teams.
  • Maven for build management: once we decided on Eclipse, Git and Jetty, Maven kind of fell in place as a natural choice, since it worked well with all of the above.
  • Bugzilla for bug tracking: it’s a great tool, with a simple, flexible interface and it has matured very nicely over the past decade.

All of this has worked out quite well, and we would recommend this stack for other startups that are looking to develop Web applications.

Using Kerika to QA itself

Kerika, Technology

Since we are developing software for helping distributed teams collaborate more effectively, it was only natural that we would set up our own team as a distributed one.

Working remotely and relying principally on electronic communications, supplemented by some in-person meetings, has helped us understand better the challenges faced by distributed teams. As we believed from the outset, the biggest challenge has been keeping everyone on the same page in terms of our company strategy: business strategy, marketing strategy, and product roadmap.

Throughout our development process one of us would bemoan the lack of software like Kerika, that could help us build software like Kerika… Once the product became usable enough, we started “dogfooding” it –that elegant phrase invented by Microsoft that refers to a product team “eating it’s own dog food.”

One of the ways in which the Kerika team is using Kerika is for our QA: whenever we decide to work on a bug, we create a new project and name it after that bug number. Inside, we put our Build Verification Test (BVT) as well as the exit (success) criteria for that particular bug. It’s a neat trick: by going through the BVT, which we use as a sanity test before the developers hand off their code for QA, we end up creating a mini Kerika project for each bug.

For example, our BVT requires developers to upload a document to a Kerika page: well, for each bug, we upload a document that represents the exit criteria for that particular bug. The BVT requires users to go through various steps that provide a general coverage of Kerika’s main features. This means logging in using at least 3 different browsers (we usually test with Firefox, Safari and Chrome), and going through the process of adding Web links, videos, etc.

By using Kerika to test Kerika, at the end of each bug’s coding cycle we have a new project that we can look at and see whether it passed the BVT. It’s self-referential: the existence of a correctly set up project, with a particular team consisting of both Team Members and Visitors who perform certain actions, confirms that the BVT passed.

We combine the BVT with the exit criteria for each bug: these are derived from the reproduction steps of the bug report, plus the functional specifications. Going through the exit criteria for a particular bug, we end up with items in that bug’s project folder that confirm whether the bug was successfully fixed.

For example, if there was a bug about embedding YouTube videos on Kerika pages, the exit criteria would be such that at the end of the developer’s testing, the project would contain a YouTube video that could be examined to confirm that the bug was fixed.

So if the project for that bug is set up correctly at the end of the bug-specific repro steps and the BVT, then the developer knows he can check in his code for QA on our test environment. Of course, during our QA cycle we do more extensive testing, but this initial use of Kerika helps developers avoid breaking the build when they check in the code.

Pretty neat way of dogfooding, wouldn’t you agree?

Hello once again, world!

Kerika

After a rather long hiatus (over three years!), Kerika is back, and with a bang!

We owe the world some explanation of why Kerika disappeared, and why it is now reappearing…

Here’s what happened: when we launched Kerika back in 2006, it was as a desktop application, written entirely in Java so that it would run on Windows, Macs and Linux computers. People really liked the concept, particularly the innovative user interface and the ease with which one could do document management. But, there were two serious drawbacks with that first version:

  • The biggest problem was our reliance upon JXTA, an open-source peer-to-peer communication technology that had been hatched at Sun Microsystems (remember them?) by none other than the legendary Bill Joy. On paper, JXTA looked perfect: it’s theoretical model and architecture exactly matched our needs. In practice, however, it proved to be a disastrous technology choice.
  • The other big problem we had was that Kerika 1.0 was a desktop application, which meant that it needed to get downloaded, and users needed to configure their firewalls to let the JXTA traffic go through. This proved to be a huge hurdle for many people who were interested in the product, but couldn’t get it past their IT gatekeepers.

Eventually, we ran out of time and money, which is really the same thing from a startup’s perspective. Of the two flaws listed above, the dependency on JXTA was really the killer: it meant that we couldn’t reliably provide communication or transfer of files between users. (And the topic of JXTA really merits its own blog post.)

And, so, we had to pack up our tents and go get “regular” jobs.

That’s the story of why Kerika disappeared.

What’s more interesting, is the story of why Kerika is now reappearing:

A funny thing happened, in the 3 years that Kerika v1 was taken off the market: people kept writing in asking for the product. (We had never taken down the website, so the demos were still available; you just couldn’t download the product any more.)

This got us thinking that maybe Kerika was fundamentally a good idea, but we had screwed up the execution of that idea. And there was another thing that surprised us: in the intervening years, no one else released anything like Kerika –a flexible whiteboard on which you could sketch out your ideas and plans, and also embed your content.

Last Spring, we sent an email to our old user base, trying to understand better what it was they found attractive about Kerika, and, in the process, trying to gauge the interest in reviving the product. The replies we received convinced us that (a) Kerika was, fundamentally, a good idea, at heart, and (b) the needs it served were still not being met by anything else in the market.

In August we reconstituted the Kerika team: a different team than before, with the skills that we would need to rebuild Kerika, from scratch, as a Web application. We have been hard at work ever since, and have done a compete rebuild – not a single line of code was reused! – and now we are ready to present to you the fruits of our labors.

In the next few blog posts, we will talk about the new product, the challenges we faced, the choices we made, and the lessons we learned from Kerika v1 (or “K1” as we like to call it.)

Welcome back.